Podcasts about Google App Engine

An airhacks.fm conversation with Kelsey Hightower (@kelseyhightower) about: HP laptop and playing Age of Empires, programming calculators with TI-BASIC, playing Mario on NES, enjoying the Metroid on NES, working at Google datacenter as contractor, bash is a programming language, working for a financial institution, modernising COBOL with Java, rewriting Cobol to python, learning Java and using JBoss, contributing to Python to make it better, venv (virtualenv) and pypy, using Puppet for configuration management, python vs. Ruby, overengineering with Java, Java is lean now, creeating the confd project, envsubst and Java, Cost Driven Architectures in the clouds, replacing Java with GO, starting at CoreOS, etcd as coordinator, implementation of RAFT, RAFT and cluster membership, contributing to Packr and Terraform, docker is written in GO, RAFT is understandable Paxos, RAFT did not consider bootstrapping, Apache zookeeper is used for coordination, Apache BookKeeper, CoreOS fleet, rkt vs. docker, salt configuration maangement, kubernetes pod, the status field in kubernetes, Google Service Weaver, Google App Engine, checkout episode: "#153 Java, Serverless, Google App Engine, gVisor, Kubernetes", writing modular code is important, monoliths and microservices, rust is leaking details, Kubernetes The Hard Way the step by step guide, Kubernetes Autopilot Kelsey Hightower on twitter: @kelseyhightower

Today's guest is Nick Johnson, the founder and lead developer of ENS. Ethereum Name Service (ENS) is a distributed, open, and extensible naming system based on the Ethereum blockchain. ENS converts human-readable Ethereum addresses like john.eth into the machine-readable alphanumeric codes you know from wallets like Metamask. The reverse conversion -- associating metadata and machine-readable addresses with human-readable Ethereum addresses -- is also possible. Nick previously worked as a software engineer at Ethereum from June 2016 to August 2018, where they implemented a trending system to identify trending terms on Lumi, improved integration with Twitter, and made significant improvements to the efficiency, scalability, and monitoring of backend systems. Prior to Ethereum, Nick worked as a senior software engineer at Google from June 2014 to June 2016. At Google, they were a primary point of contact for external developers with questions and problems using Google App Engine, and they wrote client libraries and SDK code to improve the user experience with App Engine. Nick also wrote extensive technical blog posts to help users with specific App Engine technologies, and they gave talks at high profile technical conferences around the world on subjects related to App Engine development. Nick Johnson completed a BSc in Computer Science at the University of Canterbury. We discuss a variety of topics including ENS, Digital Identities, Ethereum, Web3, and much more. We begin our conversation by discussing Nick's journey to crypto and why he is so passionate about wallet addresses. Nick shares his first experience with Bitcoin but didn't really understand the value proposition. Nick explains how crypto eventually clicked for him when he discovered Ethereum. Nick shares his experience working for the Ethereum foundation. We discuss the various tradeoffs between working for startups versus the corporate environment. Nick shares how NameCoin was an inspiration for ENS and how they were able to learn from NameCoin's mistakes. We discuss what we are most excited about the upcoming trends for 2023. Nick shares why he is very excited of ZK-rollups. We discuss the relationship between ENS labs and the ENS DAO. We focus on the future of DAOs and why it is so disruptive. We discuss the organizational structure of DAOs and the importance of proper identity verification practices for DAOs. Nick explains the importance of removing the politicking and governance capture in DAOs. We discuss how Web3 enables people to own their digital identity. Our final conversation topic centered around ENS's 2023 roadmap. Nick discusses their upcoming Name Wrapper and their commitment to long term sustainability. Please enjoy my conversation with Nick Johnson.

https://podcasts.mongodb.com/public/115/The-MongoDB-Podcast-b02cf624/f96bd55fTranscriptMichael Lynn: Welcome to the show. My name is Michael Lynn and this is the MongoDB Podcast. Thanks for joining us. Today on the show, Lena Smart, Chief Security Officer of MongoDB, and I team up to interview Dwight Merriman, co- founder and key contributor to MongoDB. Dwight Merriman is a true tech legend. In addition to co- founding and co- creating the MongoDB database and 10gen now called MongoDB, the company. He also co- founded and led several other well known successful companies including Business Insider, DoubleClick and Gilt Groupe. In today's interview, Dwight shares openly and honestly about the motivations behind creating the database, which now actually claims nearly half of the entire NoSQL market. He talks about the decision to build the database rather than use something that existed at the time. Dwight's friendly, easy to talk to, knowledgeable, and probably one of the smartest individuals that I've had the pleasure of chatting with. Without further ado, let's get to the interview. If you enjoy the content, please consider visiting Apple Podcasts or Spotify. Leave a rating and a comment if you're able, let us know what you think. Stay tuned. Hey, did you know that MongoDB University has been completely redesigned? That's right. Hands- on labs, quizzes, study guides and materials, bite- sized video lectures, programming language specific courses. You can learn MongoDB in the programming language of your choice, Node. js, Python, C#, Java, so many more. You can earn that MongoDB certification by validating your skills and leveling up your career. Visit learn. mongodb. com today.Lena Smart: So it is my absolute pleasure, and I'm so glad that you could make it in person today, to introduce Dwight Merriman. He is the first CEO of MongoDB, and you were still coding, I understand. You're also co- founder and director of MongoDB as of today. Are you still coding?Dwight Merriman: I'm still coding or tinkering a bit myself, but not on the database anymore. I think there's, to really dive in and work on it, there's a certain minimum number of hours a week you have to work on it, just to keep up with the code base and the state of everything, because it's not short, it's not a small program anymore.Lena Smart: Amazing. And also in the room we have Mike Lynn, who's our developer advocate, and I know that you'll likely have some questions.Michael Lynn: Yeah, for sure.Lena Smart: And just fire ahead, because probably this will be the most interesting person I'll speak to in a inaudible too.Michael Lynn: Well I'm fascinated already and I've got so many questions for Dwight, but I'm going to let you go ahead and ask away.Lena Smart: Cool. So the first question I have, and this has been a burning question of mine since I joined three and a half years ago, is how did you start the company? How did you start MongoDB?Dwight Merriman: Right, so when we started, actually the name of the company was 10gen, and this was around 2008, or I forget the date, maybe two months before that, I can't remember. The original, what we were really looking at, at the time, is as myself and our other co- founders like Elliot and Kevin, we've been working on various entrepreneurial projects, and we were seeing this repeated pattern where over and over. New product idea, you start building the system. At this point, I've been doing that for quite a long time. So knew what the best practices were at the time. But it was always around that timeframe, January, 2008, whenever it was, it just seemed like it was always a bit awkward. There was awkward and un- anesthetic, and it just seemed like there was a lot of duct tape and rubber bands. And even though those were best practices. You would talk to CTOs at the time, and they would say things like, " Putting memcached in front of databases is okay, and roll your own sharding in front of my MySQL sequel or Postgres is okay, but it isn't. It was because there wasn't a better way at the time. And everything, that was really when the cloud computing EC2 was really taking off. So it was very clear to us that cloud computing was the future, and a lot of the traditional products weren't very cloud- friendly. So if you have a database that scales vertically, so I can make it bigger, but then it's a mainframe, or a Sun 6500 or something like that, that's the opposite of a cloud principle, which is horizontal scalability and elasticity. And then if you tried to do it the other way, horizontally, it was usually rolling your own when it came to operational databases. And a lot of other things, but also just agile development was the way to go then, all iterative development. But a lot of the old tools, and this isn't just databases, but languages, everything, weren't really designed for that, because they were invented earlier. So it's not their fault. So we were just saying, " Gee, there's got to be a better way to develop applications," and this is both on the how to develop them, how to code them, and also on how to scale them, and how to run them in the cloud painlessly. So our first concept was just we were going to do platform as a service. So we were going to try to do a fresh take on the developer stack, versus LAMP and whatever else was common then. And see what we could come up with. So we started building a platform as a service system. It was open source and this was very early. So I think when we went to beta, it was almost exactly the same time that Google's, was it Google App Engine?Lena Smart: Yeah.Dwight Merriman: It's the same time it came out to beta. So our timing was, it was like when they came out with it. And I was like, "Oh, okay, somebody there's thinking similar thoughts." And so that was fine. But a few months later, as we got a little further into it, I was thinking about it and I was like, I'm looking at things like AWS, where they have all these microservices. And they're like, " I'm not going to give you a full cloud platform. I'm going to give you some building box for your toolbox, and over time I'll give you more." Because the scope is large, so today they have a lot of services, but this, we're 15 years later- ish. So if I give you a platform though, to give you everything you need really, it's a big scope, and it's going to take quite a while to build it. So I think platform as a service makes sense, but we got further into it, and we had something working analogous to Google App Engine, or I guess, Heroku was around back then. It just felt like, " Boy, to get this true maturity, there's so many pieces that you would want in it. It's going to take a long time. This is, it's going to take a decade or something." And for a startup you only have so much runway. And it's now even today platform as a service, I think, is a valid notion and concept, but it's certainly not mature yet. The more AWS style or microservices- style approach, which you could do on all the big cloud platforms today, I just, I say AWS because I'm just contrasting it with the PaaS vendors back in the day, approach is still the dominant approach. So we've been building this, and really what were we building? So we're trying to build something where you'd write some code, you put it in inaudible, then you would just click Deploy. And it would deploy your app into our system in the cloud, try to handle scaling for you, including things like app server layer, app tier, how many app servers should there be, and low balancing for that. All this is just happening automatically. You don't have to think about it at all. So it's really trying to eliminate a lot of the operational overhead. It's just, give you a platform. It's like, " Here's my app, I've written all the code, deploy it." And it just happens, and you don't think about machines at all. So this is an aspiration. Obviously what we built, there's a little bit about machines, if we look at today with MongoDB and sharding, and things like that. I mean we do have things like Serverless, but we also have things like sharding where, as the person developing a system, how many shards you have, you can change it, but it's not like it's just completely opaque in that sense. And likewise in your replica sets, have control over how many copies of things there are. But conception, that was the path. We were looking at completely elastic, serverless too. But as we looked at it, we also were thinking about what would we want if we were building a new app or system. And there's certain features I wanted from the data layer, and if you really went to something that was just 100% inaudible, infinitely scalable and so forth, you're getting into things that were more like the early Amazon Dynamo stuff, where they're more, at least back then, it was just more a key value store, key document store, if you will. You didn't have the rich database functionality. So we didn't want to throw out tons and tons of data layer functionality. So our approach was, it had some traditional elements to it, but then we tried to innovate on those. And it's like, yes, it's sharded, but it's auto- sharded. You can, it'll do it, you don't have to write it yourself. And the replication, it's still replication, but it's a lot more sophisticated than the traditional just primary- secondary model, and push button on a lot of these things. So we've been building this platform, we had the app layer, data layer, and then it's just like, " Gee, this is such a large scope for a startup." We didn't have many people at the time, and it was maybe I feel like we should just do one or the other. We should do this, the app layer of the platform, or the data layer. So if we look back at Heroku, their data layer was Postgres, right? That's how they reduced the scope. And then in the end we decided to focus on data layer, because we were in beta with the platform.Michael Lynn: What was the platform called by the way?Dwight Merriman: 10gen.Michael Lynn: 10gen? Okay.Dwight Merriman: And then we called the data layer MongoDB. And since it was sort of a module or a component, we didn't mind using a slightly cheeky name, because it wasn't the name of the whole product at the time. But actually the background on the name, is that the concept of the Mongo is it's the middle of the word, " Humongous," and half of the point was the horizontal scalability, or easy scalability of the product. And then the other half is of developer productivity and agility. That's where the name came from. So it was the name of the subsystem. And then it's like, " Okay, that's all we're going to do now, instead of the whole platform." So there was a pivot if you will, which we did very early. Things were going fine, but we were getting very good feedback on the beta of the platform. But I was just thinking ahead in how this plays out. And it was like, " This is a lot to do." And also the rate of the adoption of that model. But then thinking about, " Well, do we do the app layer or the data layer to cut the scope?" We were getting really good feedback on the data layer of the platform from the beta testers. So they were like, " Hey, I really like this." So that helped us feel like, " Okay, maybe let's just take the data layer, let's un- bundle it from this platform as a service- thing and just make it a database, open source database, you could run anywhere." And so we just pulled it out of the code base so it was its own thing. And then it's like, " Well, I guess we need to write some drivers." So we spent a month or two running drivers, and then we released version 0. 9. And then it was just all we were working on, was MongoDB, and that was the company.Michael Lynn: What drove the decision to go open source?Lena Smart: Mm- hmm. That was going to be my question. Thank you.Michael Lynn: Sorry.Dwight Merriman: It seemed pretty clear to us that the traditional enterprise model was changing. And obviously there was a lot of things that were open source at the time. There's a lot of things that were SaaS, and then there's some things that were freemium, that seemed like the options that people were doing for new stuff, were those three. They weren't the classic enterprise software. They were maybe free. For example, I hope, I don't get this wrong, but I think Splunk, it was free for a small amount of data, and then it turned into more enterprise software. And then of course you had any things that are SaaS, or maybe you call it infrastructure as a service, you pay for what you use, and then there's just the open source stuff. So we felt like, " Okay, we are a startup, how do we get awareness, branding, adoption?" People that try it as a startup, they're very big companies. Some of the biggest companies in the world have databases, and how do we compete with them? How do we compete with Oracle, how do we compete with Amazon? Things like this. And it seems like the open source is the asymmetry there that lets you compete with them. At the same time, it was clear that things were moving into the cloud. So when we're thinking about open source licenses, obviously you could go all the way down to BSD license, it's just free, and that's great if you're, especially for a community project. But we had investors and things like that. So we need a way to have revenue eventually, we wanted a license with more like a copyleft. It's like GPL. But with everything moving into the cloud, the traditional GPL copyleft doesn't really work. So this was clear enough to us even in 2008. So we made the license AGPL. I think, it was one of the first projects that was AGPL, and it seemed like that was the right way to go at the time. And I felt like, I was CEO at the time, so I was pretty involved in the decision. So it seemed like, " Well, if it's a problem, we can always just dual license it and with another license that's more flexible." You can't go from a very-Michael Lynn: Permissive?Dwight Merriman: Yeah, permissive license to a less permissive license. But you can go the other way, because you could still keep the other license available if you liked it, and you don't want to even go read the new one. But then you could dual license and have something more permissive. So I thought we can always go more permissive, we can't go less permissive really. And then three years ago, we actually switched the license from AGPL to this new license called SSPL, Server Side Public license, which is, it's super similar to AGPL, but if you did a inaudible on it, it's only a couple sentences are different I think. But this was a big decision we didn't take lightly, because obviously all the old releases are still available on AGPL. So it was just on a forward basis, it's like, " Let's use this SSPL thing we came up with." Which is just basically saying if what you're building is just purely a database, like a general purpose database, then you're subject to the copyleft. And this was coming out of some analysis of AGPL, and it was not totally clear that it did what the original intent was, that it totally worked legally. So we thought we needed to do that. That did push the product and the license into a slightly gray area, where there's a classic definition of open source software. Which is, there's no restrictions on how you can use it. So with GPL, you triggered a copyleft by distribution. It's not how you're using it in your application with this, it's actually, well it sort of triggers on how you use it. So if you're doing something like Amazon RDS with the MongoDB source code, it would trigger.Michael Lynn: So it's offering it, offering your software as a service?Dwight Merriman: Yeah. Basically Mongo as a service, and if you offer that, you can do it with SSPL, but then you trigger the copyleft, and you have to release your code just like you did with GPL. So you could still do something like inaudible version of Mongo if you wanted it as a service. So it was really a response to things, where the cloud providers, not just Amazon, I'm not trying to pick on them, but with RDS, they're just taking every open source database, and they're making a nice wrapped management layer on it. But then it's like, no, we don't have any direct customers anymore And they wouldn't be paying us, I think. So that was the notion. So it gets gray then, and a purist might say, " Well, that's not open source." But I think in practice it's completely practical. If you're doing applications, you can definitely use it for free and without any encumbrances. So I think the whole notion of how we define open source, and the licenses inaudible, and the definition thereof, I think is, right now, it's in a transitional stage, where it needs to be iterated on. Because I love open source, but given these cloud models, and if you wanted to do anything that had a copyleft, it just doesn't, the old ones don't work anymore. So now we've seen, since we did that, many other projects have done similar things. And I think from some of the standards bodies, why we predict we're going to see some new things that are in the spirit of that. But were definitely not available when we thought we needed it, because we talked to them, and the speed of motion wasn't working for us. So I think in practice, basically nothing changes. You're making an app, you want to use MongoDB, you know you can use it for free. Your code is your code, you don't have to release it, or anything. You haven't triggered a copyleft there. In practice, I think it works great. But if you're an open source specialist, theorist, you write licenses and stuff, you might quibble.Lena Smart: That was fascinating.

An airhacks.fm conversation with Geertjan Wielenga (@GeertjanW) about: ZX Spectrum 48k, Pascal and Basic programming at high school, studying law in South Africa, writing documentation at Sun Microsystems for netbeans, Ludovic Champenois on "#153 Java, Serverless, Google App Engine, gVisor, Kubernetes", working for Sun Microsystems in Prague, mike's blog, GlassFish Grizzly, NetBeans RCP, monitoring oil platforms with NetBeans RCP, Victor Orozco on: "#192 Innovation, Clouds, Kubernetes, Standards and Java", NetBeans certification and knowledge sharing, the great performance of NetBeans 15, the Swing Application Framework and JSR-296 and JSR-295, JSR 296: Swing Application Framework, JDeveloper used NetBeans as platform, from Oracle to Apache NetBeans, the challenges of opensourcing code, Geertjan Wielenga on twitter: @GeertjanW

Cet épisode marathon sera découpé en deux morceaux pour éviter à vos oreilles une écoute marathon. Dans cet épisode on y parle Brian Goetz, Bian Goetz, Brian Goetz, usages des threads virtuels, OpenAPI, Kubernetes, KNative, copilot et Tekton. La deuxième partie couvrira des sujets d'architecture et de loi société et organisation ainsi que les conférences à venir. Enregistré le 8 juillet 2022 Téléchargement de l'épisode LesCastCodeurs-Episode–281.mp3 News Langages Peut-être une nouvelle syntaxe spécifique aux Records Java pour tordre le cou aux builders Brian Goetz discute de l'idée d'avoir une syntaxe spécifique pour les records pour facilement créer un record dérivé, potentiellement avec des valeurs par défaut, mais en paramétrant certains champs Point shadowPos = shape.position() with { x = 0 } Cela évite de créer la notion de paramètre par défaut dans les constructeurs ou les méthodes Il y a l'article Data Oriented Programming de Brian Goetz, sur InfoQ projet Amber amène des changements qui combinés permet de faire du data oriented programming en Java et pas que du OOP OO combine état et comportement (code) OO est super utile pour défendre des limites (programme large en des limites plus petites et plus gérable) mais on s'oriente vers des applications plus petites (microservices) data oriented programming: modélise data immuable et le code de la logique métier est séparée records -> data en tant que classe, sealed classes -> définir des choix, pattern matching -> raisonne sur des data polymorphiques algebraic data: hiérarchie de sealed classes dont les feuilles sont des records: nommées, immuable, testable (pas de code) Un nouveau JEP pour intégrer une Classfile API Le JDK inclut déjà des forks de ASM, de BCEL, et d'autres APIs internes, pour manipuler / produire / lire le bytecode Mais l'idée ici c'est que le JDK vienne avec sa propre API officielle, et qui soit plus sympa à utiliser aussi que le pattern visiteur de ASM par exemple La version d'ASM intégrée était toujours en retard d'une version (problème de poule et d'oeuf, car ASM doit supporter la dernière version de Java, mais Java n+1 n'est pas encore sorti) Lilian nous montre à quoi va ressembler les Record Patterns de JEP 405 Apache Groovy et les virtual threads, et aussi Groovy et le Deep Learning Paul King, qui dirige actuellement le PMC de Apache Groovy, a partagé récemment plusieurs articles sur le blog d'Apache sur des intégrations intéressantes avec Groovy Groovy et sa librairie GPars pour la programmation concurrente et parallèle s'intègre facilement avec les Virtual Threads de JEP 425 / JDK 19 https://blogs.apache.org/groovy/entry/gpars-meets-virtual-threads Groovy avec Apache Wayang et Apache Spark pour classifier des Whiskey par clusterisation KMeans https://blogs.apache.org/groovy/entry/using-groovy-with-apache-wayang Et aussi Groovy avec différentes librairies de Deep Learning pour la classification https://blogs.apache.org/groovy/entry/classifying-iris-flowers-with-deep Le jargon (en anglais) de la programmation fonctionnelle, si vous avez rêvé d'avoir sous la main la définition de foncteur, de monoïde, et j'en passe avec des exemples en JavaScript des pointeurs vers des librairies fonctionnelles en JavaScript des traductions dans d'autres langues et d'autres langages de programmation Librairies Spring Boot 2.7 SpringBoot 2.7 Spring GraphQL 1.0 Support pour Podman Gestion de dépendance et auto configuration pour Cache2k nouvelle annotations pour Elasticsearch et CouchBase dernière versions avant SpringBoot 3 qui changera plus de choses. Recommande de migrer une version a la fois. Support pour 2.5 à fini (upstream) Quarkus 2.10.0 Travaux préliminaires sur les threads virtuels de Loom Support non-blocking pour GraphQL Prise en charge des Kubernetes service binding pour les clients SQL réactifs CacheKeyGenerator pour l'extension de cache quarkus-bootstrap-maven-plugin déprécié et remplacé par quarkus-extension-maven-plugin (uniquement utile pour les développeurs d'extensions Quarkus) Nouveaux guides: Using Stork with Kubernetes OpenId Connect Client Reference Guide Using Podman with Quarkus Les différences entre OpenAPI 2 et 3 Introduction de la notion de lien pour créer des relations entre Response et Operations, pratique pour faire des APIs hypermédia La structure du document OpenAPI a été -un peu simplifiée, en combinant par exemple basePath et schemes, ou en rassemblant les securityDefinitions Des améliorations sur les security schemes, autour de OAuth et OpenID Plus de clarté dans la négociation de contenu et les cookies La section des exemples de Request / Response devrait aider les outils qui génèrent par exemple des SDK automatiquement à partir de la description OpenAPI Un support étendu de JSON Schema Introduction d'une notion de Callback, importante pour les APIs asynchrones, en particulier les WebHooks je me demande si ils ont l'intention d'embrasser AsyncAPI ou su la partie asynchrone d'OpenAPI 3 a pour objectif de faire de la competition Infrastructure N'utilisez pas Kubernetes tout de suite ! Kubernetes, c'est bien, mais c'est un gros marteau. Est-ce que vous avez des gros clous à enfoncer ? Ne commencez peut-être pas avec l'artillerie lourde de Kubernetes. Commencez plutôt avec des solutions managées genre serverless, ce sera plus simple, et au fur et à mesure si votre infrastructure a besoin de grossir et dépasse les fonctionnalités des solutions managées, à ce moment là seulement évaluer si Kubernetes peut répondre à votre besoin Choisir Kubernetes, c'est aussi avoir la taille de l'équipe qui va bien avec, et il faut des profils DevOps, SRE, etc, pour gérer un cluster K8S L'auteur suggère grosso modo que ça dépend de l'ordre de magnitude de la taille de l'équipe : avec quelques personnes, préférez des solutions type Google App Engine ou AWS App Runner, avec une dizaine de personne peut-être du Google Cloud Run ou AWS Fargate, avec moins d'une centaine là pourquoi pas du Kubernetes managé comme Google Kubernetes Engine, et si vous dépassez mille, alors peut-être vos propres clusters managés par vos soins et hébergés par vos soins sur votre infra ca impose d'utiliser les services du cloud provider? Parce que la vie ce n'est pas que du code maison. C'est la mode de dire de pas utiliser K8S : https://www.jeremybrown.tech/8-kubernetes-is-a-red-flag-signalling-premature-optimisation/ (mais bon, vu le nombre de fois où il est pas utilisé à b Knative Eventing Devlivery methods on peut faire de la delviery simple 1–1 sans garantie on peut faire de la delivery complexe et persistante en introduisant la notion de channel qui decouple la source de la destination. on peut repondre a la reception d'un message et pousser la réponse dans un second channel mais ca devient compliquer a gérer quand on rajoute des souscripteurs il y a la notiuon de broker qui definit: des flitres, un channel (automatique) et la capacité de répondre les triggers sont un abonnement non pas a un channel mais a un type d'évènement spécifique Cloud AWS is Windows and Kube is Linux pourquoi utilisez Kube qui etait pas stablewa lors qu'AWS offre tout AWS forcé d'offrir EKS MAis pourri Lockin AWSIAM Pourquoi AWS serait le windows economies d'echelles de faire chez soi kube devient rentable une certaine taille de l'organisation besoin alternative a AWS (bus factor) on voit le Kube distro modele arriver Google data center Paris Outillage IntelliJ IDEA 2022.5 EAP 5 amène des nouveautés Frameworks and Technologies Spring 6 and Spring Boot 3 Support for new declarative HTTP Clients in Spring 6 URL completion and navigation for Spring Cloud Gateway routes Experimental GraalVM Native Debugger for Java Code insight improvements for JVM microservices test and mock frameworks Code insight improvements for Spring Shell Improved support for JAX-RS endpoints Support for WebSockets endpoints in HTTP Client Support for GraphQL endpoints in the HTTP Client UI/UX improvements for the HTTP Client Improved navigation between Protobuf and Java sources Kubernetes and Docker Intercept Kubernetes service requests with Telepresence integration Upload local Docker image to Minikube and other connections Docker auto-connection at IDE restart Docker connection options for different docker daemons GitHub copilot est disponible pour tous (les developpeurs) 40% du code écrit est généré par copilot en python (ca calme) gratuit pour les étudiants et les développeurs OSS Revue de Redmonk décrit copilot comme une extension d'intelligence ou auto complete mais qui « comprend » le code autour premiere fois pas une boite de cette taille et à cette échelle l'avantage de copilot en terme de productivité, de qualité de code, de sécurité et de légalité En gros, c'est encore à voir. Mais la qualité impressionne les gens qui l'ont testé ; sécurité pas de retour d'un côté ou de l'autre sauf que les développeurs humains ne sont pas des lumières de sécurité :D GitHub pense que GitHub n'est pas responsable de la violation de code vue que ce sont des machines et des algorithmes qui transforment: cela a l'air d'etre le consensus des avocats GitHub dit qu'on est responsable du code qu'on écrit avec copilot Et implicitement GitHub dit que la licensure du code « source » ne se propage pas au code generé. Et là, c'est pas clair et de la responsibilité de l'utilisateur, mais la encore les avocats sont plutot ok moralement c'est probablement pas ok mais bon et il y a débat autour des licenses copyleft notamment LGPL 1% du temps, code copié verbatim de > 150 caractères Question sur le code non open source sur lequel GitHub Copilot s'appuie mais en gros le marcher s'en fout un peu des licences Risque de reputation de Microsoft la question c'est quand / si les gens seront prêt à accepter cet usage Gradle publie sa roadmap Historiquement, la société Gradle Inc ne publiait pas vraiment de roadmap officielle Outre les tickets que l'on pouvait voir dans Github, cette fois ci, une “roadmap board” est visible et disponible pour tout le monde, et pas seulement pour les clients Tekton est groovy (mais non, il n'utilise pas Groovy !) Un grand tutoriel sur Tekton Une brève histoire de CI/CD (avec un contraste avec Groovy utilisé dans Jenkins) Un aperçu des grands concepts de Tekton, avec ses tâches et ses pipelines (Task, TaskRun, Pipeline, PipelineRun) Comment installer Tekton Les outils CLI Un exemple concret d'utilisation Sortie de Vim 9, surtout avec VimScript 9 des changements incompatibles entre VimScript 8.2 et 9 font qu'il était nécessaire de passer à une version majeure mais l'ancienne version du langage reste supportée pour compatibilité avec la nouvelle, les utilisateurs peuvent s'attendre à des performances x10 voire x100 ! le langage devient pré-compilé, au lieu d'être interprété ligne par ligne l'idée était d'avoir un langage plus proche de ce qu'on trouve dans JavaScript, TypeScript ou Java Conférences De la part de Youen Cette année Codeurs en Seine, c'est le 17 novembre et le cfp est ouvert N'hésitez pas à amener un peu de JVM dans l'appel à orateur. (ca commence à se faire rare). Pour rappel : codeurs en seine c'est 1000 personnes autour des métiers du développement dans une des plus grande salle de Rouen, le kindarena. 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/

Show Notes(01:41) Mars walked through his education studying Computer Systems Engineering at The University of Auckland in New Zealand.(03:16) Mars reflected on his overall Ph.D. experience in Computer Science at UCLA.(05:55) Mars discussed his early research paper on a robust and scalable lane departure warning system for smartphones.(07:13) Mars described his work on SmartFall, an automatic fall detection system to help prevent the elderly from falling.(08:34) Mars explained his project WANDA, an end-to-end remote health monitoring and analytics system designed for heart failure patients.(10:06) Mars recalled learnings from interning as a software engineer at Google during his Ph.D.(14:54) Mars discussed engineering challenges while working on PHP for Google App Engine and Gboard personalization during his subsequent four years at Google.(19:05) Mars rationalized his decision to join LinkedIn to lead an engineering team that builds the core metadata infrastructure for the entire organization.(21:15) Mars discussed the motivation behind the creation of LinkedIn's generalized metadata search and discovery tool, DataHub, later open-sourced in 2020.(25:21) Mars dissected the key architecture of DataHub, which is designed to address the key scalability challenges coming in four different forms: modeling, ingestion, serving, and indexing.(28:50) Mars expressed the challenges of finding DataHub's early adopters internally at LinkedIn and externally later on at other companies.(35:22) Mars shared the story behind the founding of Metaphor Data, which he co-founded with Pardhu Gunnam and Seyi Adebajo and currently serves as the CTO.(41:55) Mars unpacked how Metaphor's modern metadata platform serves as a system of record for any organization's data ecosystem.(48:07) Mars described new challenges with metadata management since the introduction of the modern data stack and key features of a great modern metadata platform (as brought up in his in-depth blog post with Ben Lorica).(53:55) Mars explained how a modern metadata platform fits within the broader data ecosystem.(58:30) Mars shared the hurdles to finding Metaphor Data's early design partners and lighthouse customers.(01:04:33) Mars shared valuable hiring lessons to attract the right people who are excited about Metaphor's mission.(01:07:28) Mars shared important culture-building lessons to build out a high-performing team at Metaphor.(01:10:45) Mars shared fundraising advice for founders currently seeking the right investors for their startups.(01:13:22) Closing segment.Mars' Contact InfoTwitterLinkedInGoogle ScholarGitHubMetaphor DataWebsite | Twitter | LinkedInCareers | About PageData Documentation | Data CollaborationMentioned ContentArticlesDataHub: A generalized metadata search and discovery tool (Aug 2019)Open-sourcing DataHub: LinkedIn's metadata search and discovery platform (Feb 2020)Founding Metaphor Data (Dec 2020)Metaphor and Soda partner to unify the modern data stack with trusted data (Dec 2021)Introducing Metaphor: The Modern Metadata Platform (Nov 2021)The Modern Metadata Platform: What, Why, and How? (Jan 2022)PapersSmartLDWS: A robust and scalable lane departure warning system for the smartphones (Oct 2009)SmartFall: An automatic fall detection system based on subsequence matching for the SmartCane (April 2009)WANDA: An end-to-end remote health monitoring and analytics system for heart failure patients (Oct 2012)PeopleBenn Stancil (Chief Analytics Officer at Mode Analytics, Well-Known Substack Writer)Tristan Handy (Co-Founder and CEO of dbt Labs, Writer of The Analytics Engineering Roundup)Andy Pavlo (Associate Professor of Database at Carnegie Mellon University)Books“Working In Public” (by Nadia Eghbal)“The Mom Test” (by Rob Fitzpatrick)“A Thousand Brains” (by Jeff Hawkins)“The Scout Mindset” (by Julia Galef)NotesMy conversation with Mars was recorded back in January 2022. Since then, many things have happened at Metaphor Data. I'd recommend:Visiting their brand new websiteReading the 3-part “Data Documentation” series on their blog (part 1, part 2, and part 3)Looking over the Trusted Data landing pageAbout the showDatacast features long-form, in-depth conversations with practitioners and researchers in the data community to walk through their professional journeys and unpack the lessons learned along the way. I invite guests coming from a wide range of career paths — from scientists and analysts to founders and investors — to analyze the case for using data in the real world and extract their mental models (“the WHY and the HOW”) behind their pursuits. Hopefully, these conversations can serve as valuable tools for early-stage data professionals as they navigate their own careers in the exciting data universe.Datacast is produced and edited by James Le. Get in touch with feedback or guest suggestions by emailing khanhle.1013@gmail.com.Subscribe by searching for Datacast wherever you get podcasts or click one of the links below:Listen on SpotifyListen on Apple PodcastsListen on Google PodcastsIf you're new, see the podcast homepage for the most recent episodes to listen to, or browse the full guest list.

About TimTimothy William Bray is a Canadian software developer, environmentalist, political activist and one of the co-authors of the original XML specification. He worked for Amazon Web Services from December 2014 until May 2020 when he quit due to concerns over the terminating of whistleblowers. Previously he has been employed by Google, Sun Microsystemsand Digital Equipment Corporation (DEC). Bray has also founded or co-founded several start-ups such as Antarctica Systems.Links Referenced: Textuality Services: https://www.textuality.com/ laugh]. So, the impetus for having this conversation is, you had a [blog post: https://www.tbray.org/ongoing/When/202x/2022/01/30/Cloud-Lock-In @timbray: https://twitter.com/timbray tbray.org: https://tbray.org duckbillgroup.com: https://duckbillgroup.com 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 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: Couchbase Capella Database-as-a-Service is flexible, full-featured and fully managed with built in access via key-value, SQL, and full-text search. Flexible JSON documents aligned to your applications and workloads. Build faster with blazing fast in-memory performance and automated replication and scaling while reducing cost. Capella has the best price performance of any fully managed document database. Visit couchbase.com/screaminginthecloud to try Capella today for free and be up and running in three minutes with no credit card required. Couchbase Capella: make your data sing.Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today has been on a year or two ago, but today, we're going in a bit of a different direction. Tim Bray is a principal at Textuality Services.Once upon a time, he was a Distinguished Engineer slash VP at AWS, but let's be clear, he isn't solely focused on one company; he also used to work at Google. Also, there is scuttlebutt that he might have had something to do, at one point, with the creation of God's true language, XML. Tim, thank you for coming back on the show and suffering my slings and arrows.Tim: Oh, you're just fine. Glad to be here.Corey: [laugh]. So, the impetus for having this conversation is, you had a blog post somewhat recently—by which I mean, January of 2022—where you talked about lock-in and multi-cloud, two subjects near and dear to my heart, mostly because I have what I thought was a fairly countercultural opinion. You seem to have a very closely aligned perspective on this. But let's not get too far ahead of ourselves. Where did this blog posts come from?Tim: Well, I advised a couple of companies and one of them happens to be using GCP and the other happens to be using AWS and I get involved in a lot of industry conversations, and I noticed that multi-cloud is a buzzword. If you go and type multi-cloud into Google, you get, like, a page of people saying, “We will solve your multi-cloud problems. Come to us and you will be multi-cloud.” And I was not sure what to think, so I started writing to find out what I would think. And I think it's not complicated anymore. I think the multi-cloud is a reality in most companies. I think that many mainstream, non-startup companies are really worried about cloud lock-in, and that's not entirely unreasonable. So, it's a reasonable thing to think about and it's a reasonable thing to try and find the right balance between avoiding lock-in and not slowing yourself down. And the issues were interesting. What was surprising is that I published that blog piece saying what I thought were some kind of controversial things, and I got no pushback. Which was, you know, why I started talking to you and saying, “Corey, you know, does nobody disagree with this? Do you disagree with this? Maybe we should have a talk and see if this is just the new conventional wisdom.”Corey: There's nothing worse than almost trying to pick a fight, but no one actually winds up taking you up on the opportunity. That always feels a little off. Let's break it down into two issues because I would argue that they are intertwined, but not necessarily the same thing. Let's start with multi-cloud because it turns out that there's just enough nuance to—at least where I sit on this position—that whenever I tweet about it, I wind up getting wildly misinterpreted. Do you find that as well?Tim: Not so much. It's not a subject I have really had too much to say about, but it does mean lots of different things. And so it's not totally surprising that that happens. I mean, some people think when you say multi-cloud, you mean, “Well, I'm going to take my strategic application, and I'm going to run it in parallel on AWS and GCP because that way, I'll be more resilient and other good things will happen.” And then there's another thing, which is that, “Well, you know, as my company grows, I'm naturally going to be using lots of different technologies and that might include more than one cloud.” So, there's a whole spectrum of things that multi-cloud could mean. So, I guess when we talk about it, we probably owe it to our audiences to be clear what we're talking about.Corey: Let's be clear, from my perspective, the common definition of multi-cloud is whatever the person talking is trying to sell you at that point in time is, of course, what multi-cloud is. If it's a third-party dashboard, for example, “Oh, yeah, you want to be able to look at all of your cloud usage on a single pane of glass.” If it's a certain—well, I guess, certain not a given cloud provider, well, they understand if you go all-in on a cloud provider, it's probably not going to be them so they're, of course, going to talk about multi-cloud. And if it's AWS, where they are the 8000-pound gorilla in the space, “Oh, yeah, multi-clouds, terrible. Put everything on AWS. The end.” It seems that most people who talk about this have a very self-serving motivation that they can't entirely escape. That bias does reflect itself.Tim: That's true. When I joined AWS, which was around 2014, the PR line was a very hard line. “Well, multi-cloud that's not something you should invest in.” And I've noticed that the conversation online has become much softer. And I think one reason for that is that going all-in on a single cloud is at least possible when you're a startup, but if you're a big company, you know, a insurance company, a tire manufacturer, that kind of thing, you're going to be multi-cloud, for the same reason that they already have COBOL on the mainframe and Java on the old Sun boxes, and Mongo running somewhere else, and five different programming languages.And that's just the way big companies are, it's a consequence of M&A, it's a consequence of research projects that succeeded, one kind or another. I mean, lots of big companies have been trying to get rid of COBOL for decades, literally, [laugh] and not succeeding and doing that. So—Corey: It's ‘legacy' which is, of course, the condescending engineering term for, “It makes money.”Tim: And works. And so I don't think it's realistic to, as a matter of principle, not be multi-cloud.Corey: Let's define our terms a little more closely because very often, people like to pull strange gotchas out of the air. Because when I talk about this, I'm talking about—like, when I speak about it off the cuff, I'm thinking in terms of where do I run my containers? Where do I run my virtual machines? Where does my database live? But you can also move in a bunch of different directions. Where do my Git repositories live? What Office suite am I using? What am I using for my CRM? Et cetera, et cetera? Where do you draw the boundary lines because it's very easy to talk past each other if we're not careful here?Tim: Right. And, you know, let's grant that if you're a mainstream enterprise, you're running your Office automation on Microsoft, and they're twisting your arm to use the cloud version, so you probably are. And if you have any sense at all, you're not running your own Exchange Server, so let's assume that you're using Microsoft Azure for that. And you're running Salesforce, and that means you're on Salesforce's cloud. And a lot of other Software-as-a-Service offerings might be on AWS or Azure or GCP; they don't even tell you.So, I think probably the crucial issue that we should focus our conversation on is my own apps, my own software that is my core competence that I actually use to run the core of my business. And typically, that's the only place where a company would and should invest serious engineering resources to build software. And that's where the question comes, where should that software that I'm going to build run? And should it run on just one cloud, or—Corey: I found that when I gave a conference talk on this, in the before times, I had to have a ever lengthier section about, “I'm speaking in the general sense; there are specific cases where it does make sense for you to go in a multi-cloud direction.” And when I'm talking about multi-cloud, I'm not necessarily talking about Workload A lives on Azure and Workload B lives on AWS, through mergers, or weird corporate approaches, or shadow IT that—surprise—that's not revenue-bearing. Well, I guess we have to live with it. There are a lot of different divisions doing different things and you're going to see that a fair bit. And I'm not convinced that's a terrible idea as such. I'm talking about the single workload that we're going to spread across two or more clouds, intentionally.Tim: That's probably not a good idea. I just can't see that being a good idea, simply because you get into a problem of just terminology and semantics. You know, the different providers mean different things by the word ‘region' and the word ‘instance,' and things like that. And then there's the people problem. I mean, I don't think I personally know anybody who would claim to be able to build and deploy an application on AWS and also on GCP. I'm sure some people exist, but I don't know any of them.Corey: Well, Forrest Brazeal was deep in the AWS weeds and now he's the head of content at Google Cloud. I will credit him that he probably has learned to smack an API around over there.Tim: But you know, you're going to have a hard time hiring a person like that.Corey: Yeah. You can count these people almost as individuals.Tim: And that's a big problem. And you know, in a lot of cases, it's clearly the case that our profession is talent-starved—I mean, the whole world is talent-starved at the moment, but our profession in particular—and a lot of the decisions about what you can build and what you can do are highly contingent on who you can hire. And you can't hire a multi-cloud expert, well, you should not deploy, [laugh] you know, a multi-cloud application.Now, having said that, I just want to dot this i here and say that it can be made to kind of work. I've got this one company I advise—I wrote about it in the blog piece—that used to be on AWS and switched over to GCP. I don't even know why; this happened before I joined them. And they have a lot of applications and then they have some integrations with third-party partners which they implemented with AWS Lambda functions. So, when they moved over to GCP, they didn't stop doing that.So, this mission-critical latency-sensitive application of theirs runs on GCP that calls out to AWS to make calls into their partners' APIs and so on. And works fine. Solid as a rock, reliable, low latency. And so I talked to a person I know who knows over on the AWS side, and they said, “Oh, yeah sure, you know, we talked to those guys. Lots of people do that. We make sure, you know, the connections are low latency and solid.” So, technically speaking, it can be done. But for a variety of business reasons—maybe the most important one being expertise and who you can hire—it's probably just not a good idea.Corey: One of the areas where I think is an exception case is if you are a SaaS provider. Let's pick a big easy example: Snowflake, where they are a data warehouse. They've got to run their data warehousing application in all of the major clouds because that is where their customers are. And it turns out that if you're going to send a few petabytes into a data warehouse, you really don't want to be paying cloud egress rates to do it because it turns out, you can just bootstrap a second company for that much money.Tim: Well, Zoom would be another example, obviously.Corey: Oh, yeah. Anything that's heavy on data transfer is going to be a strange one. And there's being close to customers; gaming companies are another good example on this where a lot of the game servers themselves will be spread across a bunch of different providers, just purely based on latency metrics around what is close to certain customer clusters.Tim: I can't disagree with that. You know, I wonder how large a segment that is, of people who are, I think you're talking about core technology companies. Now, of the potential customers of the cloud providers, how many of them are core technology companies, like the kind we're talking about, who have such a need, and how many people who just are people who just want to run their manufacturing and product design and stuff. And for those, buying into a particular cloud is probably a perfectly sensible choice.Corey: I've also seen regulatory stories about this. I haven't been able to track them down specifically, but there is a pervasive belief that one interpretation of UK banking regulations stipulates that you have to be able to get back up and running within 30 days on a different cloud provider entirely. And also, they have the regulatory requirement that I believe the data remain in-country. So, that's a little odd. And honestly, when it comes to best practices and how you should architect things, I'm going to take a distinct backseat to legal requirements imposed upon you by your regulator. But let's be clear here, I'm not advising people to go and tell their auditors that they're wrong on these things.Tim: I had not heard that story, but you know, it sounds plausible. So, I wonder if that is actually in effect, which is to say, could a huge British banking company, in fact do that? Could they in fact, decamp from Azure and move over to GCP or AWS in 30 days? Boy.Corey: That is what one bank I spoke to over there was insistent on. A second bank I spoke to in that same jurisdiction had never heard of such a thing, so I feel like a lot of this is subject to auditor interpretation. Again, I am not an expert in this space. I do not pretend to be—I know I'm that rarest of all breeds: A white guy with a microphone in tech who admits he doesn't know something. But here we are.Tim: Yeah, I mean, I imagine it could be plausible if you didn't use any higher-level services, and you just, you know, rented instances and were careful about which version of Linux you ran and we're just running a bunch of Java code, which actually, you know, describes the workload of a lot of financial institutions. So, it should be a matter of getting… all the right instances configured and the JVM configured and launched. I mean, there are no… architecturally terrifying barriers to doing that. Of course, to do that, it would mean you would have to avoid using any of the higher-level services that are particular to any cloud provider and basically just treat them as people you rent boxes from, which is probably not a good choice for other business reasons.Corey: Which can also include things as seemingly low-level is load balancers, just based upon different provisioning modes, failure modes, and the rest. You're probably going to have a more consistent experience running HAProxy or nginx yourself to do it. But Tim, I have it on good authority that this is the old way of thinking, and that Kubernetes solves all of it. And through the power of containers and powers combining and whatnot, that frees us from being beholden to any given provider and our workloads are now all free as birds.Tim: Well, I will go as far as saying that if you are in the position of trying to be portable, probably using containers is a smart thing to do because that's a more tractable level of abstraction that does give you some insulation from, you know, which version of Linux you're running and things like that. The proposition that configuring and running Kubernetes is easier than configuring and running [laugh] JVM on Linux [laugh] is unsupported by any evidence I've seen. So, I'm dubious of the proposition that operating at the Kubernetes-level at the [unintelligible 00:14:42] level, you know, there's good reasons why some people want to do that, but I'm dubious of the proposition that really makes you more portable in an essential way.Corey: Well, you're also not the target market for Kubernetes. You have worked at multiple cloud providers and I feel like the real advantage of Kubernetes is people who happen to want to protect that they do so they can act as a sort of a cosplay of being their own cloud provider by running all the intricacies of Kubernetes. I'm halfway kidding, but there is an uncomfortable element of truth to that to some of the conversations I've had with some of its more, shall we say, fanatical adherents.Tim: Well, I think you and I are neither of us huge fans of Kubernetes, but my reasons are maybe a little different. Kubernetes does some really useful things. It really, really does. It allows you to take n VMs, and pack m different applications onto them in a way that takes reasonably good advantage of the processing power they have. And it allows you to have different things running in one place with different IP addresses.It sounds straightforward, but that turns out to be really helpful in a lot of ways. So, I'm actually kind of sympathetic with what Kubernetes is trying to be. My big gripe with it is that I think that good technology should make easy things easy and difficult things possible, and I think Kubernetes fails the first test there. I think the complexity that it involves is out of balance with the benefits you get. There's a lot of really, really smart people who disagree with me, so this is not a hill I'm going to die on.Corey: This is very much one of those areas where reasonable people can disagree. I find the complexity to be overwhelming; it has to collapse. At this point, it's finding someone who can competently run Kubernetes in production is a bit hard to do and they tend to be extremely expensive. You aren't going to find a team of those people at every company that wants to do things like this, and they're certainly not going to be able to find it in their budget in many cases. So, it's a challenging thing to do.Tim: Well, that's true. And another thing is that once you step onto the Kubernetes slope, you start looking about Istio and Envoy and [fabric 00:16:48] technology. And we're talking about extreme complexity squared at that point. But you know, here's the thing is, back in 2018 I think it was, in his keynote, Werner said that the big goal is that all the code you ever write should be application logic that delivers business value, which you know rep—Corey: Didn't CGI say the same thing? Didn't—like, isn't there, like, a long history dating back longer than I believe either of us have been alive have, “With this, all you're going to write is business logic.” That was the Java promise. That was the Google App Engine promise. Again, and again, we've had that carrot dangled in front of us, and it feels like the reality with Lambda is, the only code you will write is not necessarily business logic, it's getting the thing to speak to the other service you're trying to get it to talk to because a lot of these integrations are super finicky. At least back when I started learning how this stuff worked, they were.Tim: People understand where the pain points are and are indeed working on them. But I think we can agree that if you believe in that as a goal—which I still do; I mean, we may not have got there, but it's still a worthwhile goal to work on. We can agree that wrangling Istio configurations is not such a thing; it's not [laugh] directly value-adding business logic. To the extent that you can do that, I think serverless provides a plausible way forward. Now, you can be all cynical about, “Well, I still have trouble making my Lambda to talk to my other thing.” But you know, I've done that, and I've also deployed JVM on bare metal kind of thing.You know what? I'd rather do things at the Lambda level. I really rather would. Because capacity forecasting is a horribly difficult thing, we're all terrible at it, and the penalties for being wrong are really bad. If you under-specify your capacity, your customers have a lousy experience, and if you over-specify it, and you have an architecture that makes you configure for peak load, you're going to spend bucket-loads of money that you don't need to.Corey: “But you're then putting your availability in the cloud providers' hands.” “Yeah, you already were. Now, we're just being explicit about acknowledging that.”Tim: Yeah. Yeah, absolutely. And that's highly relevant to the current discussion because if you use the higher-level serverless function if you decide, okay, I'm going to go with Lambda and Dynamo and EventBridge and that kind of thing, well, that's not portable at all. I mean, APIs are totally idiosyncratic for AWS and GCP's equivalent, and Azure's—what do they call it? Permanent functions or something-a-rather functions. So yeah, that's part of the trade-off you have to think about. If you're going to do that, you're definitely not going to be multi-cloud in that application.Corey: And in many cases, one of the stated goals for going multi-cloud is that you can avoid the downtime of a single provider. People love to point at the big AWS outages or, “See? They were down for half a day.” And there is a societal question of what happens when everyone is down for half a day at the same time, but in most cases, what I'm seeing, your instead of getting rid of a single point of failure, introducing a second one. If either one of them is down your applications down, so you've doubled your outage surface area.On the rare occasions where you're able to map your dependencies appropriately, great. Are your third-party critical providers all doing the same? If you're an e-commerce site and Stripe processes your payments, well, they're public about being all-in on AWS. So, if you can't process payments, does it really matter that your website stays up? It becomes an interesting question. And those are the ones that you know about, let alone the third, fourth-order dependencies that are almost impossible to map unless everyone is as diligent as you are. It's a heavy, heavy lift.Tim: I'm going to push back a little bit. Now, for example, this company I'm advising that running GCP and calling out to Lambda is in that position; either GCP or Lambda goes off the air. On the other hand, if you've got somebody like Zoom, they're probably running parallel full stacks on the different cloud providers. And if you're doing that, then you can at least plausibly claim that you're in a good place because if Dynamo has an outage—and everything relies on Dynamo—then you shift your load over to GCP or Oracle [laugh] and you're still on the air.Corey: Yeah, but what is up as well because Zoom loves to sign me out on my desktop whenever I log into it on my laptop, and vice versa, and I wonder if that authentication and login system is also replicated full-stack to everywhere it goes, and what the fencing on that looks like, and how the communication between all those things works? I wouldn't doubt that it's possible that they've solved for this, but I also wonder how thoroughly they've really tested all of the, too. Not because I question them any; just because this stuff is super intricate as you start tracing it down into the nitty-gritty levels of the madness that consumes all these abstractions.Tim: Well, right, that's a conventional wisdom that is really wise and true, which is that if you have software that is alleged to do something like allow you to get going on another cloud, unless you've tested it within the last three weeks, it's not going to work when you need it.Corey: Oh, it's like a DR exercise: The next commit you make breaks it. Once you have the thing working again, it sits around as a binder, and it's a best guess. And let's be serious, a lot of these DR exercises presume that you're able to, for example, change DNS records on the fly, or be able to get a virtual machine provisioned in less than 45 minutes—because when there's an actual outage, surprise, everyone's trying to do the same things—there's a lot of stuff in there that gets really wonky at weird levels.Tim: A related similar exercise, which is people who want to be on AWS but want to be multi-region. It's actually, you know, a fairly similar kind of problem. If I need to be able to fail out of us-east-1—well, God help you, because if you need to everybody else needs to as well—but you know, would that work?Corey: Before you go multi-cloud go multi-region first. Tell me how easy it is because then you have full-feature parity—presumably—between everything; it should just be a walk in the park. Send me a postcard once you get that set up and I'll eat a bunch of words. And it turns out, basically, no one does.Tim: Mm-hm.Corey: Another area of lock-in around a lot of this stuff, and I think that makes it very hard to go multi-cloud is the security model of how does that interface with various aspects. In many cases, I'm seeing people doing full-on network overlays. They don't have to worry about the different security group models and VPCs and all the rest. They can just treat everything as a node sitting on the internet, and the only thing it talks to is an overlay network. Which is terrible, but that seems to be one of the only ways people are able to build things that span multiple providers with any degree of success.Tim: Well, that is painful because, much as we all like to scoff and so on, in the degree of complexity you get into there, it is the case that your typical public cloud provider can do security better than you can. They just can. It's a fact of life. And if you're using a public cloud provider and not taking advantage of their security offerings, infrastructure, that's probably dumb. But if you really want to be multi-cloud, you kind of have to, as you said.In particular, this gets back to the problem of expertise because it's hard enough to hire somebody who really understands IAM deeply and how to get that working properly, try and find somebody who can understand that level of thing on two different cloud providers at once. Oh, gosh.Corey: This episode is sponsored in part by LaunchDarkly. Take a look at what it takes to get your code into production. I'm going to just guess that it's awful because it's always awful. No one loves their deployment process. What if launching new features didn't require you to do a full-on code and possibly infrastructure deploy? What if you could test on a small subset of users and then roll it back immediately if results aren't what you expect? LaunchDarkly does exactly this. To learn more, visit launchdarkly.com and tell them Corey sent you, and watch for the wince.Corey: Another point you made in your blog post was the idea of lock-in, of people being worried that going all-in on a provider was setting them up to be, I think Oracle is the term that was tossed around where once you're dependent on a provider, what's to stop them from cranking the pricing knobs until you squeal?Tim: Nothing. And I think that is a perfectly sane thing to worry about. Now, in the short term, based on my personal experience working with, you know, AWS leadership, I think that it's probably not a big short-term risk. AWS is clearly aware that most of the growth is still in front of them. You know, the amount of all of it that's on the cloud is still pretty small and so the thing to worry about right now is growth.And they are really, really genuinely, sincerely focused on customer success and will bend over backwards to deal with the customers problems as they are. And I've seen places where people have negotiated a huge multi-year enterprise agreement based on Reserved Instances or something like that, and then realize, oh, wait, we need to switch our whole technology stack, but you've got us by the RIs and AWS will say, “No, no, it's okay. We'll tear that up and rewrite it and get you where you need to go.” So, in the short term, between now and 2025, would I worry about my cloud provider doing that? Probably not so much.But let's go a little further out. Let's say it's, you know, 2030 or something like that, and at that point, you know, Andy Jassy decided to be a full-time sports mogul, and Satya Narayana has gone off to be a recreational sailboat owner or something like that, and private equity operators come in and take very significant stakes in the public cloud providers, and get a lot of their guys on the board, and you have a very different dynamic. And you have something that starts to feel like Oracle where their priority isn't, you know, optimizing for growth and customer success; their priority is optimizing for a quarterly bottom line, and—Corey: Revenue extraction becomes the goal.Tim: That's absolutely right. And this is not a hypothetical scenario; it's happened. Most large companies do not control the amount of money they spend per year to have desktop software that works. They pay whatever Microsoft's going to say they pay because they don't have a choice. And a lot of companies are in the same situation with their database.They don't get to budget, their database budget. Oracle comes in and says, “Here's what you're going to pay,” and that's what you pay. You really don't want to be in a situation with your cloud, and that's why I think it's perfectly reasonable for somebody who is doing cloud transition at a major financial or manufacturing or service provider company to have an eye to this. You know, let's not completely ignore the lock-in issue.Corey: There is a significant scale with enterprise deals and contracts. There is almost always a contractual provision that says if you're going to raise a price with any cloud provider, there's a fixed period of time of notice you must give before it happens. I feel like the first mover there winds up getting soaked because everyone is going to panic and migrate in other directions. I mean, Google tried it with Google Maps for their API, and not quite Google Cloud, but also scared the bejesus out of a whole bunch of people who were, “Wait. Is this a harbinger of things to come?”Tim: Well, not in the short term, I don't think. And I think you know, Google Maps [is absurdly 00:26:36] underpriced. That's hellishly expensive service. And it's supposed to pay for itself by, you know, advertising on maps. I don't know about that.I would see that as the exception rather than the rule. I think that it's reasonable to expect cloud prices, nominally at least, to go on decreasing for at least the short term, maybe even the medium term. But that's—can't go on forever.Corey: It also feels to me, like having looked at an awful lot of AWS environments that if there were to be some sort of regulatory action or some really weird outage for a year that meant that AWS could not onboard a single new customer, their revenue year-over-year would continue to increase purely by organic growth because there is no forcing function that turns the thing off when you're done using it. In fact, they can migrate things around to hardware that works, they can continue building you for the things sitting there idle. And there is no governance path on that. So, on some level, winding up doing a price increase is going to cause a massive company focus on fixing a lot of that. It feels on some level like it is drawing attention to a thing that they don't really want to draw attention to from a purely revenue extraction story.When CentOS back-walked their ten-year support line two years, suddenly—and with an idea that it would drive [unintelligible 00:27:56] adoption. Well, suddenly, a lot of people looked at their environment, saw they had old [unintelligible 00:28:00] they weren't using. And massively short-sighted, massively irritated a whole bunch of people who needed that in the short term, but by the renewal, we're going to be on to Ubuntu or something else. It feels like it's going to backfire massively, and I'd like to imagine the strategist of whoever takes the reins of these companies is going to be smarter than that. But here we are.Tim: Here we are. And you know it's interesting you should mention regulatory action. At the moment, there are only three credible public cloud providers. It's not obvious the Google's really in it for the long haul, as last time I checked, they were claiming to maybe be breaking even on it. That's not a good number, you know? You'd like there to be more than that.And if it goes on like that, eventually, some politician is going to say, “Oh, maybe they should be regulated like public utilities,” because they kind of are right? And I would think that anybody who did get into Oracle-izing would be—you know, accelerate that happening. Having said that, we do live in the atmosphere of 21st-century capitalism, and growth is the God that must be worshiped at all costs. Who knows. It's a cloudy future. Hard to see.Corey: It really is. I also want to be clear, on some level, that with Google's current position, if they weren't taking a small loss at least, on these things, I would worry. Like, wait, you're trying to catch AWS and you don't have anything better to invest that money into than just well time to start taking profits from it. So, I can see both sides of that one.Tim: Right. And as I keep saying, I've already said once during this slot, you know, the total cloud spend in the world is probably on the order of one or two-hundred billion per annum, and global IT is in multiple trillions. So, [laugh] there's a lot more space for growth. Years and years worth of it.Corey: Yeah. The challenge, too, is that people are worried about this long-term strategic point of view. So, one thing you talked about in your blog post is the idea of using hosted open-source solutions. Like, instead of using Kinesis, you'd wind up using Kafka or instead of using DynamoDB you use their managed Cassandra service—or as I think of it Amazon Basics Cassandra—and effectively going down the path of letting them manage this thing, but you then have a theoretical Exodus path. Where do you land on that?Tim: I think that speaks to a lot of people's concerns, and I've had conversations with really smart people about that who like that idea. Now, to be realistic, it doesn't make migration easy because you've still got all the CI and CD and monitoring and management and scaling and alarms and alerts and paging and et cetera, et cetera, et cetera, wrapped around it. So, it's not as though you could just pick up your managed Kafka off AWS and drop a huge installation onto GCP easily. But at least, you know, your data plan APIs are the same, so a lot of your code would probably still run okay. So, it's a plausible path forward. And when people say, “I want to do that,” well, it does mean that you can't go all serverless. But it's not a totally insane path forward.Corey: So, one last point in your blog post that I think a lot of people think about only after they get bitten by it is the idea of data gravity. I alluded earlier in our conversation to data egress charges, but my experience has been that where your data lives is effectively where the rest of your cloud usage tends to aggregate. How do you see it?Tim: Well, it's a real issue, but I think it might perhaps be a little overblown. People throw the term petabytes around, and people don't realize how big a petabyte is. A petabyte is just an insanely huge amount of data, and the notion of transmitting one over the internet is terrifying. And there are lots of enterprises that have multiple petabytes around, and so they think, “Well, you know, it would take me 26 years to transmit that, so I can't.”And they might be wrong. The internet's getting faster all time. Did you notice? I've been able to move some—for purely personal projects—insane amounts of data, and it gets there a lot faster than you did. Secondly, in the case of AWS Snowmobile, we have an existence proof that you can do exabyte-ish scale data transfers in the time it takes to drive a truck across the country.Corey: Inbound only. Snowmobiles are not—at least according to public examples—are valid for Exodus.Tim: But you know, this is kind of place where regulatory action might come into play if what the people were doing was seen to be abusive. I mean, there's an existence proof you can do this thing. But here's another point. So, I suppose you have, like, 15 petabytes—that's an insane amount of data—displayed in your corporate application. So, are you actually using that to run the application, or is a huge proportion of that stuff just logs and data gathered of various kinds that's being used in analytics applications and AI models and so on?Do you actually need all that data to actually run your app? And could you in fact, just pick up the stuff you need for your app, move it to a different cloud provider from there and leave your analytics on the first one? Not a totally insane idea.Corey: It's not a terrible idea at all. It comes down to the idea as well of when you're trying to run a query against a bunch of that data, do you need all the data to transit or just the results of that query, as well? It's a question of, can you move the compute closer to the data as opposed to the data to where the compute lives?Tim: Well, you know and a lot of those people who have those huge data pools have it sitting on S3, and a lot of it migrated off into Glacier, so it's not as if you could get at it in milliseconds anyhow. I just ask myself, “How much data can anybody actually use in a day? In the course of satisfying some transaction requests from a customer?” And I think it's not petabyte. It just isn't.Now, there are—okay, there are exceptions. There's the intelligence community, there's the oil drilling community, there are some communities who genuinely will use insanely huge seas of data on a routine basis, but you know, I think that's kind of a corner case, so before you shake your head and say, “Ah, they'll never move because the data gravity,” you know… you need to prove that to me and I might be a little bit skeptical.Corey: And I think that is probably a very fair request. Just tell me what it is you're going to be doing here to validate the idea that is in your head because the most interesting lies I've found customers tell isn't intentionally to me or anyone else; it's to themselves. The narrative of what they think they're doing from the early days takes root, and never mind the fact that, yeah, it turns out that now that you've scaled out, maybe development isn't 80% of your cloud bill anymore. You learn things and your understanding of what you're doing has to evolve with the evolution of the applications.Tim: Yep. It's a fun time to be around. I mean, it's so great; right at the moment lock-in just isn't that big an issue. And let's be clear—I'm sure you'll agree with me on this, Corey—is if you're a startup and you're trying to grow and scale and prove you've got a viable business, and show that you have exponential growth and so on, don't think about lock-in; just don't go near it. Pick a cloud provider, pick whichever cloud provider your CTO already knows how to use, and just go all-in on them, and use all their most advanced features and be serverless if you can. It's the only sane way forward. You're short of time, you're short of money, you need growth.Corey: “Well, what if you need to move strategically in five years?” You should be so lucky. Great. Deal with it then. Or, “Well, what if we want to sell to retail as our primary market and they hate AWS?”Well, go all-in on a provider; probably not that one. Pick a different provider and go all in. I do not care which cloud any given company picks. Go with what's right for you, but then go all in because until you have a compelling reason to do otherwise, you're going to spend more time solving global problems locally.Tim: That's right. And we've never actually said this probably because it's something that both you and I know at the core of our being, but it probably needs to be said that being multi-cloud is expensive, right? Because the nouns and verbs that describe what clouds do are different in Google-land and AWS-land; they're just different. And it's hard to think about those things. And you lose the capability of using the advanced serverless stuff. There are a whole bunch of costs to being multi-cloud.Now, maybe if you're existentially afraid of lock-in, you don't care. But for I think most normal people, ugh, it's expensive.Corey: Pay now or pay later, you will pay. Wouldn't you ideally like to see that dollar go as far as possible? I'm right there with you because it's not just the actual infrastructure costs that's expensive, it costs something far more dear and expensive, and that is the cognitive expense of having to think about both of these things, not just how each cloud provider works, but how each one breaks. You've done this stuff longer than I have; I don't think that either of us trust a system that we don't understand the failure cases for and how it's going to degrade. It's, “Oh, right. You built something new and awesome. Awesome. How does it fall over? What direction is it going to hit, so what side should I not stand on?” It's based on an understanding of what you're about to blow holes in.Tim: That's right. And you know, I think particularly if you're using AWS heavily, you know that there are some things that you might as well bet your business on because, you know, if they're down, so is the rest of the world, and who cares? And, other things, eh, maybe a little chance here. So, understanding failure modes, understanding your stuff, you know, the cost of sharp edges, understanding manageability issues. It's not obvious.Corey: It's really not. Tim, I want to thank you for taking the time to go through this, frankly, excellent post with me. If people want to learn more about how you see things, and I guess how you view the world, where's the best place to find you?Tim: I'm on Twitter, just @timbray T-I-M-B-R-A-Y. And my blog is at tbray.org, and that's where that piece you were just talking about is, and that's kind of my online presence.Corey: And we will, of course, put links to it in the [show notes 00:37:42]. Thanks so much for being so generous with your time. It's always a pleasure to talk to you.Tim: Well, it's always fun to talk to somebody who has shared passions, and we clearly do.Corey: Indeed. Tim Bray principal at Textuality Services. 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 that you then need to take to all of the other podcast platforms out there purely for redundancy, so you don't get locked into one of them.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 ABAB Periasamy is the co-founder and CEO of MinIO, an open source provider of high performance, object storage software. In addition to this role, AB is an active investor and advisor to a wide range of technology companies, from H2O.ai and Manetu where he serves on the board to advisor or investor roles with Humio, Isovalent, Starburst, Yugabyte, Tetrate, Postman, Storj, Procurify, and Helpshift. Successful exits include Gitter.im (Gitlab), Treasure Data (ARM) and Fastor (SMART).AB co-founded Gluster in 2005 to commoditize scalable storage systems. As CTO, he was the primary architect and strategist for the development of the Gluster file system, a pioneer in software defined storage. After the company was acquired by Red Hat in 2011, AB joined Red Hat's Office of the CTO. Prior to Gluster, AB was CTO of California Digital Corporation, where his work led to scaling of the commodity cluster computing to supercomputing class performance. His work there resulted in the development of Lawrence Livermore Laboratory's “Thunder” code, which, at the time was the second fastest in the world.  AB holds a Computer Science Engineering degree from Annamalai University, Tamil Nadu, India.AB is one of the leading proponents and thinkers on the subject of open source software - articulating the difference between the philosophy and business model. An active contributor to a number of open source projects, he is a board member of India's Free Software Foundation.Links: MinIO: https://min.io/ Twitter: https://twitter.com/abperiasamy MinIO Slack channel: https://minio.slack.com/join/shared_invite/zt-11qsphhj7-HpmNOaIh14LHGrmndrhocA LinkedIn: https://www.linkedin.com/in/abperiasamy/ 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 Sysdig. Sysdig is the solution for securing DevOps. They have a blog post that went up recently about how an insecure AWS Lambda function could be used as a pivot point to get access into your environment. They've also gone deep in-depth with a bunch of other approaches to how DevOps and security are inextricably linked. To learn more, visit sysdig.com and tell them I sent you. That's S-Y-S-D-I-G dot com. My thanks to them for their continued support of this ridiculous nonsense.Corey: This episode is sponsored in part by our friends at Rising Cloud, which I hadn't heard of before, but they're doing something vaguely interesting here. They are using AI, which is usually where my eyes glaze over and I lose attention, but they're using it to help developers be more efficient by reducing repetitive tasks. So, the idea being that you can run stateless things without having to worry about scaling, placement, et cetera, and the rest. They claim significant cost savings, and they're able to wind up taking what you're running as it is, in AWS, with no changes, and run it inside of their data centers that span multiple regions. I'm somewhat skeptical, but their customers seem to really like them, so that's one of those areas where I really have a hard time being too snarky about it because when you solve a customer's problem, and they get out there in public and say, “We're solving a problem,” it's very hard to snark about that. Multus Medical, Construx.ai, and Stax have seen significant results by using them, and it's worth exploring. So, if you're looking for a smarter, faster, cheaper alternative to EC2, Lambda, or batch, consider checking them out. Visit risingcloud.com/benefits. That's risingcloud.com/benefits, and be sure to tell them that I said you because watching people wince when you mention my name is one of the guilty pleasures of listening to this podcast.in a siloCorey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by someone who's doing something a bit off the beaten path when we talk about cloud. I've often said that S3 is sort of a modern wonder of the world. It was the first AWS service brought into general availability. Today's promoted guest is the co-founder and CEO of MinIO, Anand Babu Periasamy, or AB as he often goes, depending upon who's talking to him. Thank you so much for taking the time to speak with me today.AB: It's wonderful to be here, Corey. Thank you for having me.Corey: So, I want to start with the obvious thing, where you take a look at what is the cloud and you can talk about AWS's ridiculous high-level managed services, like Amazon Chime. Great, we all see how that plays out. And those are the higher-level offerings, ideally aimed at problems customers have, but then they also have the baseline building blocks services, and it's hard to think of a more baseline building block than an object store. That's something every cloud provider has, regardless of how many scare quotes there are around the word cloud; everyone offers the object store. And your solution is to look at this and say, “Ah, that's a market ripe for disruption. We're going to build through an open-source community software that emulates an object store.” I would be sitting here, more or less poking fun at the idea except for the fact that you're a billion-dollar company now.AB: Yeah.Corey: How did you get here?AB: So, when we started, right, we did not actually think about cloud that way, right? “Cloud, it's a hot trend, and let's go disrupt is like that. It will lead to a lot of opportunity.” Certainly, it's true, it lead to the M&S, right, but that's not how we looked at it, right? It's a bad idea to build startups for M&A.When we looked at the problem, when we got back into this—my previous background, some may not know that it's actually a distributed file system background in the open-source space.Corey: Yeah, you were one of the co-founders of Gluster—AB: Yeah.Corey: —which I have only begrudgingly forgiven you. But please continue.AB: [laugh]. And back then we got the idea right, but the timing was wrong. And I had—while the data was beginning to grow at a crazy rate, end of the day, GlusterFS has to still look like an FS, it has to look like a file system like NetApp or EMC, and it was hugely limiting what we can do with it. The biggest problem for me was legacy systems. I have to build a modern system that is compatible with a legacy architecture, you cannot innovate.And that is where when Amazon introduced S3, back then, like, when S3 came, cloud was not big at all, right? When I look at it, the most important message of the cloud was Amazon basically threw everything that is legacy. It's not [iSCSI 00:03:21] as a Service; it's not even FTP as a Service, right? They came up with a simple, RESTful API to store your blobs, whether it's JavaScript, Android, iOS, or [AAML 00:03:30] application, or even Snowflake-type application.Corey: Oh, we spent ten years rewriting our apps to speak object store, and then they released EFS, which is NFS in the cloud. It's—AB: Yeah.Corey: —I didn't realize I could have just been stubborn and waited, and the whole problem would solve itself. But here we are. You're quite right.AB: Yeah. And even EFS and EBS are more for legacy stock can come in, buy some time, but that's not how you should stay on AWS, right? When Amazon did that, for me, that was the opportunity. I saw that… while world is going to continue to produce lots and lots of data, if I built a brand around that, I'm not going to go wrong.The problem is data at scale. And what do I do there? The opportunity I saw was, Amazon solved one of the largest problems for a long time. All the legacy systems, legacy protocols, they convinced the industry, throw them away and then start all over from scratch with the new API. While it's not compatible, it's not standard, it is ridiculously simple compared to anything else.No fstabs, no [unintelligible 00:04:27], no [root 00:04:28], nothing, right? From any application anywhere you can access was a big deal. When I saw that, I was like, “Thank you Amazon.” And I also knew Amazon would convince the industry that rewriting their application is going to be better and faster and cheaper than retrofitting legacy applications.Corey: I wonder how much that's retconned because talking to some of the people involved in the early days, they were not at all convinced they [laugh] would be able to convince the industry to do this.AB: Actually, if you talk to the analyst reporters, the IDC's, Gartner's of the world to the enterprise IT, the VMware community, they would say, “Hell no.” But if you talk to the actual application developers, data infrastructure, data architects, the actual consumers of data, for them, it was so obvious. They actually did not know how to write an fstab. The iSCSI and NFS, you can't even access across the internet, and the modern applications, they ran across the globe, in JavaScript, and all kinds of apps on the device. From [Snap 00:05:21] to Snowflake, today is built on object store. It was more natural for the applications team, but not from the infrastructure team. So, who you asked that mattered.But nevertheless, Amazon convinced the rest of the world, and our bet was that if this is going to be the future, then this is also our opportunity. S3 is going to be limited because it only runs inside AWS. Bulk of the world's data is produced everywhere and only a tiny fraction will go to AWS. And where will the rest of the data go? Not SAN, NAS, HDFS, or other blob store, Azure Blob, or GCS; it's not going to be fragmented. And if we built a better object store, lightweight, faster, simpler, but fully compatible with S3 API, we can sweep and consolidate the market. And that's what happened.Corey: And there is a lot of validity to that. We take a look across the industry, when we look at various standards—I mean, one of the big problems with multi-cloud in many respects is the APIs are not quite similar enough. And worse, the failure patterns are very different, of I don't just need to know how the load balancer works, I need to know how it breaks so I can detect and plan for that. And then you've got the whole identity problem as well, where you're trying to manage across different frames of reference as you go between providers, and leads to a bit of a mess. What is it that makes MinIO something that has been not just something that has endured since it was created, but clearly been thriving?AB: The real reason, actually is not the multi-cloud compatibility, all that, right? Like, while today, it is a big deal for the users because the deployments have grown into 10-plus petabytes, and now the infrastructure team is taking it over and consolidating across the enterprise, so now they are talking about which key management server for storing the encrypted keys, which key management server should I talk to? Look at AWS, Google, or Azure, everyone has their own proprietary API. Outside they, have [YAML2 00:07:18], HashiCorp Vault, and, like, there is no standard here. It is supposed to be a [KMIP 00:07:23] standard, but in reality, it is not. Even different versions of Vault, there are incompatibilities for us.That is where—like from Key Management Server, Identity Management Server, right, like, everything that you speak around, how do you talk to different ecosystem? That, actually, MinIO provides connectors; having the large ecosystem support and large community, we are able to address all that. Once you bring MinIO into your application stack like you would bring Elasticsearch or MongoDB or anything else as a container, your application stack is just a Kubernetes YAML file, and you roll it out on any cloud, it becomes easier for them, they're able to go to any cloud they want. But the real reason why it succeeded was not that. They actually wrote their applications as containers on Minikube, then they will push it on a CI/CD environment.They never wrote code on EC2 or ECS writing objects on S3, and they don't like the idea of [past 00:08:15], where someone is telling you just—like you saw Google App Engine never took off, right? They liked the idea, here are my building blocks. And then I would stitch them together and build my application. We were part of their application development since early days, and when the application matured, it was hard to remove. It is very much like Microsoft Windows when it grew, even though the desktop was Microsoft Windows Server was NetWare, NetWare lost the game, right?We got the ecosystem, and it was actually developer productivity, convenience, that really helped. The simplicity of MinIO, today, they are arguing that deploying MinIO inside AWS is easier through their YAML and containers than going to AWS Console and figuring out how to do it.Corey: As you take a look at how customers are adopting this, it's clear that there is some shift in this because I could see the story for something like MinIO making an awful lot of sense in a data center environment because otherwise, it's, “Great. I need to make this app work with my SAN as well as an object store.” And that's sort of a non-starter for obvious reasons. But now you're available through cloud marketplaces directly.AB: Yeah.Corey: How are you seeing adoption patterns and interactions from customers changing as the industry continues to evolve?AB: Yeah, actually, that is how my thinking was when I started. If you are inside AWS, I would myself tell them that why don't use AWS S3? And it made a lot of sense if it's on a colo or your own infrastructure, then there is an object store. It even made a lot of sense if you are deploying on Google Cloud, Azure, Alibaba Cloud, Oracle Cloud, it made a lot of sense because you wanted an S3 compatible object store. Inside AWS, why would you do it, if there is AWS S3?Nowadays, I hear funny arguments, too. They like, “Oh, I didn't know that I could use S3. Is S3 MinIO compatible?” Because they will be like, “It came along with the GitLab or GitHub Enterprise, a part of the application stack.” They didn't even know that they could actually switch it over.And otherwise, most of the time, they developed it on MinIO, now they are too lazy to switch over. That also happens. But the real reason that why it became serious for me—I ignored that the public cloud commercialization; I encouraged the community adoption. And it grew to more than a million instances, like across the cloud, like small and large, but when they start talking about paying us serious dollars, then I took it seriously. And then when I start asking them, why would you guys do it, then I got to know the real reason why they wanted to do was they want to be detached from the cloud infrastructure provider.They want to look at cloud as CPU network and drive as a service. And running their own enterprise IT was more expensive than adopting public cloud, it was productivity for them, reducing the infrastructure, people cost was a lot. It made economic sense.Corey: Oh, people always cost more the infrastructure itself does.AB: Exactly right. 70, 80%, like, goes into people, right? And enterprise IT is too slow. They cannot innovate fast, and all of those problems. But what I found was for us, while we actually build the community and customers, if you're on AWS, if you're running MinIO on EBS, EBS is three times more expensive than S3.Corey: Or a single copy of it, too, where if you're trying to go multi-AZ and you have the replication traffic, and not to mention you have to over-provision it, which is a bit of a different story as well. So, like, it winds up being something on the order of 30 times more expensive, in many cases, to do it right. So, I'm looking at this going, the economics of running this purely by itself in AWS don't make sense to me—long experience teaches me the next question of, “What am I missing?” Not, “That's ridiculous and you're doing it wrong.” There's clearly something I'm not getting. What am I missing?AB: I was telling them until we made some changes, right—because we saw a couple of things happen. I was initially like, [unintelligible 00:12:00] does not make 30 copies. It makes, like, 1.4x, 1.6x.But still, the underlying block storage is not only three times more expensive than S3, it's also slow. It's a network storage. Trying to put an object store on top of it, another, like, software-defined SAN, like EBS made no sense to me. Smaller deployments, it's okay, but you should never scale that on EBS. So, it did not make economic sense. I would never take it seriously because it would never help them grow to scale.But what changed in recent times? Amazon saw that this was not only a problem for MinIO-type players. Every database out there today, every modern database, even the message queues like Kafka, they all have gone scale-out. And they all depend on local block store and putting a scale-out distributed database, data processing engines on top of EBS would not scale. And Amazon introduced storage optimized instances. Essentially, that reduced to bet—the data infrastructure guy, data engineer, or application developer asking IT, “I want a SuperMicro, or Dell server, or even virtual machines.” That's too slow, too inefficient.They can provision these storage machines on demand, and then I can do it through Kubernetes. These two changes, all the public cloud players now adopted Kubernetes as the standard, and they have to stick to the Kubernetes API standard. If they are incompatible, they won't get adopted. And storage optimized that is local drives, these are machines, like, [I3 EN 00:13:23], like, 24 drives, they have SSDs, and fast network—like, 25-gigabit 200-gigabit type network—availability of these machines, like, what typically would run any database, HDFS cluster, MinIO, all of them, those machines are now available just like any other EC2 instance.They are efficient. You can actually put MinIO side by side to S3 and still be price competitive. And Amazon wants to—like, just like their retail marketplace, they want to compete and be open. They have enabled it. In that sense, Amazon is actually helping us. And it turned out that now I can help customers build multiple petabyte infrastructure on Amazon and still stay efficient, still stay price competitive.Corey: I would have said for a long time that if you were to ask me to build out the lingua franca of all the different cloud providers into a common API, the S3 API would be one of them. Now, you are building this out, multi-cloud, you're in all three of the major cloud marketplaces, and the way that you do that and do those deployments seems like it is the modern multi-cloud API of Kubernetes. When you first started building this, Kubernetes was very early on. What was the evolution of getting there? Or were you one of the first early-adoption customers in a Kubernetes space?AB: So, when we started, there was no Kubernetes. But we saw the problem was very clear. And there was containers, and then came Docker Compose and Swarm. Then there was Mesos, Cloud Foundry, you name it, right? Like, there was many solutions all the way up to even VMware trying to get into that space.And what did we do? Early on, I couldn't choose. I couldn't—it's not in our hands, right, who is going to be the winner, so we just simply embrace everybody. It was also tiring that to allow implement native connectors to all of them different orchestration, like Pivotal Cloud Foundry alone, they have their own standard open service broker that's only popular inside their system. Go outside elsewhere, everybody was incompatible.And outside that, even, Chef Ansible Puppet scripts, too. We just simply embraced everybody until the dust settle down. When it settled down, clearly a declarative model of Kubernetes became easier. Also Kubernetes developers understood the community well. And coming from Borg, I think they understood the right architecture. And also written in Go, unlike Java, right?It actually matters, these minute new details resonating with the infrastructure community. It took off, and then that helped us immensely. Now, it's not only Kubernetes is popular, it has become the standard, from VMware to OpenShift to all the public cloud providers, GKS, AKS, EKS, whatever, right—GKE. All of them now are basically Kubernetes standard. It made not only our life easier, it made every other [ISV 00:16:11], other open-source project, everybody now can finally write one code that can be operated portably.It is a big shift. It is not because we chose; we just watched all this, we were riding along the way. And then because we resonated with the infrastructure community, modern infrastructure is dominated by open-source. We were also the leading open-source object store, and as Kubernetes community adopted us, we were naturally embraced by the community.Corey: Back when AWS first launched with S3 as its first offering, there were a bunch of folks who were super excited, but object stores didn't make a lot of sense to them intrinsically, so they looked into this and, “Ah, I can build a file system and users base on top of S3.” And the reaction was, “Holy God don't do that.” And the way that AWS decided to discourage that behavior is a per request charge, which for most workloads is fine, whatever, but there are some that causes a significant burden. With running something like MinIO in a self-hosted way, suddenly that costing doesn't exist in the same way. Does that open the door again to so now I can use it as a file system again, in which case that just seems like using the local file system, only with extra steps?AB: Yeah.Corey: Do you see patterns that are emerging with customers' use of MinIO that you would not see with the quote-unquote, “Provider's” quote-unquote, “Native” object storage option, or do the patterns mostly look the same?AB: Yeah, if you took an application that ran on file and block and brought it over to object storage, that makes sense. But something that is competing with object store or a layer below object store, that is—end of the day that drives our block devices, you have a block interface, right—trying to bring SAN or NAS on top of object store is actually a step backwards. They completely missed the message that Amazon told that if you brought a file system interface on top of object store, you missed the point, that you are now bringing the legacy things that Amazon intentionally removed from the infrastructure. Trying to bring them on top doesn't make it any better. If you are arguing from a compatibility some legacy applications, sure, but writing a file system on top of object store will never be better than NetApp, EMC, like EMC Isilon, or anything else. Or even GlusterFS, right?But if you want a file system, I always tell the community, they ask us, “Why don't you add an FS option and do a multi-protocol system?” I tell them that the whole point of S3 is to remove all those legacy APIs. If I added POSIX, then I'll be a mediocre object storage and a terrible file system. I would never do that. But why not write a FUSE file system, right? Like, S3Fs is there.In fact, initially, for legacy compatibility, we wrote MinFS and I had to hide it. We actually archived the repository because immediately people started using it. Even simple things like end of the day, can I use Unix [Coreutils 00:19:03] like [cp, ls 00:19:04], like, all these tools I'm familiar with? If it's not file system object storage that S3 [CMD 00:19:08] or AWS CLI is, like, to bloatware. And it's not really Unix-like feeling.Then what I told them, “I'll give you a BusyBox like a single static binary, and it will give you all the Unix tools that works for local filesystem as well as object store.” That's where the [MC tool 00:19:23] came; it gives you all the Unix-like programmability, all the core tool that's object storage compatible, speaks native object store. But if I have to make object store look like a file system so UNIX tools would run, it would not only be inefficient, Unix tools never scaled for this kind of capacity.So, it would be a bad idea to take step backwards and bring legacy stuff back inside. For some very small case, if there are simple POSIX calls using [ObjectiveFs 00:19:49], S3Fs, and few, for legacy compatibility reasons makes sense, but in general, I would tell the community don't bring file and block. If you want file and block, leave those on virtual machines and leave that infrastructure in a silo and gradually phase them out.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: So, my big problem, when I look at what S3 has done is in it's name because of course, naming is hard. It's, “Simple Storage Service.” The problem I have is with the word simple because over time, S3 has gotten more and more complex under the hood. It automatically tiers data the way that customers want. And integrated with things like Athena, you can now query it directly, whenever of an object appears, you can wind up automatically firing off Lambda functions and the rest.And this is increasingly looking a lot less like a place to just dump my unstructured data, and increasingly, a lot like this is sort of a database, in some respects. Now, understand my favorite database is Route 53; I have a long and storied history of misusing services as databases. Is this one of those scenarios, or is there some legitimacy to the idea of turning this into a database?AB: Actually, there is now S3 Select API that if you're storing unstructured data like CSV, JSON, Parquet, without downloading even a compressed CSV, you can actually send a SQL query into the system. IN MinIO particularly the S3 Select is [CMD 00:21:16] optimized. We can load, like, every 64k worth of CSV lines into registers and do CMD operations. It's the fastest SQL filter out there. Now, bringing these kinds of capabilities, we are just a little bit away from a database; should we do database? I would tell definitely no.The very strength of S3 API is to actually limit all the mutations, right? Particularly if you look at database, they're dealing with metadata, and querying; the biggest value they bring is indexing the metadata. But if I'm dealing with that, then I'm dealing with really small block lots of mutations, the separation of objects storage should be dealing with persistence and not mutations. Mutations are [AWS 00:21:57] problem. Separation of database work function and persistence function is where object storage got the storage right.Otherwise, it will, they will make the mistake of doing POSIX-like behavior, and then not only bringing back all those capabilities, doing IOPS intensive workloads across the HTTP, it wouldn't make sense, right? So, object storage got the API right. But now should it be a database? So, it definitely should not be a database. In fact, I actually hate the idea of Amazon yielding to the file system developers and giving a [file three 00:22:29] hierarchical namespace so they can write nice file managers.That was a terrible idea. Writing a hierarchical namespace that's also sorted, now puts tax on how the metadata is indexed and organized. The Amazon should have left the core API very simple and told them to solve these problems outside the object store. Many application developers don't need. Amazon was trying to satisfy everybody's need. Saying no to some of these file system-type, file manager-type users, what should have been the right way.But nevertheless, adding those capabilities, eventually, now you can see, S3 is no longer simple. And we had to keep that compatibility, and I hate that part. I actually don't mind compatibility, but then doing all the wrong things that Amazon is adding, now I have to add because it's compatible. I kind of hate that, right?But now going to a database would be pushing it to the whole new level. Here is the simple reason why that's a bad idea. The right way to do database—in fact, the database industry is already going in the right direction. Unstructured data, the key-value or graph, different types of data, you cannot possibly solve all that even in a single database. They are trying to be multimodal database; even they are struggling with it.You can never be a Redis, Cassandra, like, a SQL all-in-one. They tried to say that but in reality, that you will never be better than any one of those focused database solutions out there. Trying to bring that into object store will be a mistake. Instead, let the databases focus on query language implementation and query computation, and leave the persistence to object store. So, object store can still focus on storing your database segments, the table segments, but the index is still in the memory of the database.Even the index can be snapshotted once in a while to object store, but use objects store for persistence and database for query is the right architecture. And almost all the modern databases now, from Elasticsearch to [unintelligible 00:24:21] to even Kafka, like, message queue. They all have gone that route. Even Microsoft SQL Server, Teradata, Vertica, name it, Splunk, they all have gone object storage route, too. Snowflake itself is a prime example, BigQuery and all of them.That's the right way. Databases can never be consolidated. There will be many different kinds of databases. Let them specialize on GraphQL or Graph API, or key-value, or SQL. Let them handle the indexing and persistence, they cannot handle petabytes of data. That [unintelligible 00:24:51] to object store is how the industry is shaping up, and it is going in the right direction.Corey: One of the ways I learned the most about various services is by talking to customers. Every time I think I've seen something, this is amazing. This service is something I completely understand. All I have to do is talk to one more customer. And when I was doing a bill analysis project a couple of years ago, I looked into a customer's account and saw a bucket with okay, that has 280 billion objects in it—and wait was that billion with a B?And I asked them, “So, what's going on over there?” And there's, “Well, we built our own columnar database on top of S3. This may not have been the best approach.” It's, “I'm going to stop you there. With no further context, it was not, but please continue.”It's the sort of thing that would never have occurred to me to even try, do you tend to see similar—I would say they're anti-patterns, except somehow they're made to work—in some of your customer environments, as they are using the service in ways that are very different than ways encouraged or even allowed by the native object store options?AB: Yeah, when I first started seeing the database-type workloads coming on to MinIO, I was surprised, too. That was exactly my reaction. In fact, they were storing these 256k, sometimes 64k table segments because they need to index it, right, and the table segments were anywhere between 64k to 2MB. And when they started writing table segments, it was more often [IOPS-type 00:26:22] I/O pattern, then a throughput-type pattern. Throughput is an easier problem to solve, and MinIO always saturated these 100-gigabyte NVMe-type drives, they were I/O intensive, throughput optimized.When I started seeing the database workloads, I had to optimize for small-object workloads, too. We actually did all that because eventually I got convinced the right way to build a database was to actually leave the persistence out of database; they made actually a compelling argument. If historically, I thought metadata and data, data to be very big and coming to object store make sense. Metadata should be stored in a database, and that's only index page. Take any book, the index pages are only few, database can continue to run adjacent to object store, it's a clean architecture.But why would you put database itself on object store? When I saw a transactional database like MySQL, changing the [InnoDB 00:27:14] to [RocksDB 00:27:15], and making changes at that layer to write the SS tables [unintelligible 00:27:19] to MinIO, and then I was like, where do you store the memory, the journal? They said, “That will go to Kafka.” And I was like—I thought that was insane when it started. But it continued to grow and grow.Nowadays, I see most of the databases have gone to object store, but their argument is, the databases also saw explosive growth in data. And they couldn't scale the persistence part. That is where they realized that they still got very good at the indexing part that object storage would never give. There is no API to do sophisticated query of the data. You cannot peek inside the data, you can just do streaming read and write.And that is where the databases were still necessary. But databases were also growing in data. One thing that triggered this was the use case moved from data that was generated by people to now data generated by machines. Machines means applications, all kinds of devices. Now, it's like between seven billion people to a trillion devices is how the industry is changing. And this led to lots of machine-generated, semi-structured, structured data at giant scale, coming into database. The databases need to handle scale. There was no other way to solve this problem other than leaving the—[unintelligible 00:28:31] if you looking at columnar data, most of them are machine-generated data, where else would you store? If they tried to build their own object storage embedded into the database, it would make database mentally complicated. Let them focus on what they are good at: Indexing and mutations. Pull the data table segments which are immutable, mutate in memory, and then commit them back give the right mix. What you saw what's the fastest step that happened, we saw that consistently across. Now, it is actually the standard.Corey: So, you started working on this in 2014, and here we are—what is it—eight years later now, and you've just announced a Series B of $100 million dollars on a billion-dollar valuation. So, it turns out this is not just one of those things people are using for test labs; there is significant momentum behind using this. How did you get there from—because everything you're saying makes an awful lot of sense, but it feels, at least from where I sit, to be a little bit of a niche. It's a bit of an edge case that is not the common case. Obviously, I missing something because your investors are not the types of sophisticated investors who see something ridiculous and, “Yep. That's the thing we're going to go for.” There right more than they're not.AB: Yeah. The reason for that was the saw what we were set to do. In fact, these are—if you see the lead investor, Intel, they watched us grow. They came into Series A and they saw, everyday, how we operated and grew. They believed in our message.And it was actually not about object store, right? Object storage was a means for us to get into the market. When we started, our idea was, ten years from now, what will be a big problem? A lot of times, it's hard to see the future, but if you zoom out, it's hidden in plain sight.These are simple trends. Every major trend pointed to world producing more data. No one would argue with that. If I solved one important problem that everybody is suffering, I won't go wrong. And when you solve the problem, it's about building a product with fine craftsmanship, attention to details, connecting with the user, all of that standard stuff.But I picked object storage as the problem because the industry was fragmented across many different data stores, and I knew that won't be the case ten years from now. Applications are not going to adopt different APIs across different clouds, S3 to GCS to Azure Blob to HDFS to everything is incompatible. I saw that if I built a data store for persistence, industry will consolidate around S3 API. Amazon S3, when we started, it looked like they were the giant, there was only one cloud industry, it believed mono-cloud. Almost everyone was talking to me like AWS will be the world's data center.I certainly see that possibility, Amazon is capable of doing it, but my bet was the other way, that AWS S3 will be one of many solutions, but not—if it's all incompatible, it's not going to work, industry will consolidate. Our bet was, if world is producing so much data, if you build an object store that is S3 compatible, but ended up as the leading data store of the world and owned the application ecosystem, you cannot go wrong. We kept our heads low and focused on the first six years on massive adoption, build the ecosystem to a scale where we can say now our ecosystem is equal or larger than Amazon, then we are in business. We didn't focus on commercialization; we focused on convincing the industry that this is the right technology for them to use. Once they are convinced, once you solve business problems, making money is not hard because they are already sold, they are in love with the product, then convincing them to pay is not a big deal because data is so critical, central part of their business.We didn't worry about commercialization, we worried about adoption. And once we got the adoption, now customers are coming to us and they're like, “I don't want open-source license violation. I don't want data breach or data loss.” They are trying to sell to me, and it's an easy relationship game. And it's about long-term partnership with customers.And so the business started growing, accelerating. That was the reason that now is the time to fill up the gas tank and investors were quite excited about the commercial traction as well. And all the intangible, right, how big we grew in the last few years.Corey: It really is an interesting segment, that has always been something that I've mostly ignored, like, “Oh, you want to run your own? Okay, great.” I get it; some people want to cosplay as cloud providers themselves. Awesome. There's clearly a lot more to it than that, and I'm really interested to see what the future holds for you folks.AB: Yeah, I'm excited. I think end of the day, if I solve real problems, every organization is moving from compute technology-centric to data-centric, and they're all looking at data warehouse, data lake, and whatever name they give data infrastructure. Data is now the centerpiece. Software is a commodity. That's how they are looking at it. And it is translating to each of these large organizations—actually, even the mid, even startups nowadays have petabytes of data—and I see a huge potential here. The timing is perfect for us.Corey: I'm really excited to see this continue to grow. And I want to thank you for taking so much time to speak with me today. If people want to learn more, where can they find you?AB: I'm always on the community, right. Twitter and, like, I think the Slack channel, it's quite easy to reach out to me. LinkedIn. I'm always excited to talk to our users or community.Corey: And we will of course put links to this in the [show notes 00:33:58]. Thank you so much for your time. I really appreciate it.AB: Again, wonderful to be here, Corey.Corey: Anand Babu Periasamy, CEO and co-founder of MinIO. 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 what starts out as an angry comment but eventually turns into you, in your position on the S3 product team, writing a thank you note to MinIO for helping validate your market.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.

This is a sixth episode of GCP Series which features Google App Engine. Please listen other series as well. --- Send in a voice message: https://anchor.fm/vishnu-vg/message

An airhacks.fm conversation with Ludovic Champenois (@ludoch) about: Amstrad CPC 64 with audio tape, listen to bugs, first project: a family tree in Basic, 8-bit music over gaming, learning APL with Game of Life then fortran, inventing the iPad with Apple II, Pascal and assembler, working with computers on boats with Vax VMS and Fortran, refactoring logistics software from VAX to Unix C++ and DEC Alphas, starting at Sun Microsystems in 1996, from Java 0.9 to 1.0, Javasoft vs. Sun Tools, TeamWare was like git but developed by Sun, interviewing the CEO of NetBeans at Sun, working on Netbeans Enterprise Edition, xdoclet was forbidden by Sun Microsystems, Javasoft was the church, using Netbeans at Google, improving application servers usability, writing deployment descriptors by hand, Java EE 5 was a revolution, it was impossible to write an EJB 2 with vi, starting to work on iPlanet Netscape and Sun Server, Java EE Reference Implementation was the ancestor of Glassfish, using Glassfish as Reference Implementation and commercial offering at the same time, implementing HK2 - the dependency injection for Glassfish, generating JAX-RS resources with asm, starting at the Google AppEngine Team in 2011, Google AppEngine (GAE) is one of the first Platform as a Service (PaaS) offerings, serverless and elastic Google AppEngine, GAE came with JPA-like persistence, GAE ships with a single JAR which communicates to various Google services, GAE supports Java 11, GAE supports Servlets and jetty, kubernetes was created at the GAE team, GAE is a single application running on Google's infrastructure, GAE was not able to secure Java 8 like it secured Java 6 and Java 7, using gVisor as replacement for Java's security model, gVisor is the basis of Cloud Run, gVisor rewrites syscalls, gVisor is the new implementation of the libc library, gVisor is the matrix for JVM, Ludovic's presentation about GAE: Evolution of a Platform as a Service from the inside Ludovic Champenois on twitter: @ludoch

An airhacks.fm conversation with Ruslan Synytsky (@siruslan) about: Yamaha MS 6 computer at school in Ukraine, GO SUB vs GO TO, impatience and competition, looking forward to programming at weekends, learning PL/1 on IBM, learning Delphi, writing exams software for students, building triangulation software in Delphi, earth is a potato, airhacks.live workshops at MUC airport and Greenland, Greenland is an autonomous territory withing the Kingdom of Denmark, a secret place and organization with lots of computers, a secret organization buys Sun working stations, starting to learn Java to write software for Sun Solaris on Sparcs, getting CDs full of Java and C tutorials from Sun Microsystems, writing Java software to collect and analyze geophysical data from distributed, international data centers, using GlassFish server for data collection, using web service on GlassFish and the metro webservice toolkit, writing rich UI with AJAX and JavaScript, National Data Center of Ukraine, the ticket to Antarctica, working with startups building JavaScript frontends, starting a development platform to increase the productivity, building a backend as a service (BaaS), building serverless Java solutions in 2008, scaling down from Backend as a Service to a Platform as a Service (PaaS), the screencast with Payara and Jelastic, using container runtimes for developers, serverless Payara on Jelastic, Google App Engine was the first serverless solution, building software for Data Center operators, working with James Gosling as independent director, supporting stateful workloads, using openVZ instead of containers, scaling stateless and stateful workloads, supporting Java EE and Jakarta EE runtimes in the cloud, GlassFish, Payara, WildFly and TomEE on Jelastic, Amazon's Firecracker, Jelastic uses Java to implement the cloud, paying for what you use, rightsizing with Jelastic is easy Ruslan Synytsky on twitter: @siruslan, jelastic.com and jelastic.cloud

Stephanie Wong (@swongful) and Carter Morgan (@carterthecomic) are back with a new episode of How I Launched This. This week, we talk with Pendo CEO and Co-Founder Todd Olson. With a passion for helping teams build and adapt digital products, Todd and his co-founders from Google, RedHat, and Cisco created Pendo to help companies analyze how their product offerings are used to optimize performance for customers.Pendo offers analytical tools, messaging features inside products, feedback polls, and customer feedback roadmaps to allow users to impact product development and companies to adjust products to fit real-life user needs. With situations like the global pandemic, this has become especially useful as users adjust to a new way of working with products. Pendo helps them navigate the products in these new ways and provides feedback to companies so they are able to adjust if necessary to ensure user satisfactionTodd is no stranger to startups, having launched many himself starting from a very young age. With Pendo, he wanted to focus on what users really want, what they really need, and how they're actually using products that digital engineers build. He tells us the process of Pendo's creation, starting with the initial ideas and partnering with like minded individuals. Todd feels it's important and quite honestly, more fun, to have co-founders to help support the mission and bring complimentary skills to a project.Later, we hear more about Todd's journey through entrepreneurship, from his first company to Pendo. We talk about how a lifetime of entrepreneurialism has changed him, and he tells us lessons he's learned, giving insight into the process of building a company, realizing it's potential, then moving to the next project. He details the evolution of Pendo from inception to edited iterations, to the useful service it is today. We talk about tradeoffs entrepreneurs and their startups invariably have to make and how to make the tough choices.We dig into the technology behind Pendo later in the show as Todd outlines the tools they use and why. Todd also takes the time to talk about his new book on product-led businesses. The show wraps up with a discussion of how product-led businesses can adjust for the future and embrace the changes that come with it. We end with Todd's thoughts on the future of SaaS companies. Episode Links:PendoGoogle App EngineBigQueryThe Product-Led Organization

This episode is sponsored by The Chief I/O. The Chief I/O serves Cloud-Native professionals with the knowledge and insights they need to build resilient and scalable systems and teams. Visit The Chief I/O, read our publication, and subscribe to our newsletter and RSS feed. You can also apply to become a writer. Visit www.thechief.io. In November 2017, The Register published an article, 'Lambda and serverless is one of the worst forms of proprietary lock-in we've ever seen in the history of humanity'. The article goes on and elaborates: "It's code that is tied not just to hardware – which we've seen before – but to a data center, you can't even get the hardware yourself. And that hardware is now custom fabbed for the cloud providers with dark fiber that runs all around the world, just for them. So literally, the application you write will never get the performance or responsiveness or the ability to be ported somewhere else without having the deployment footprint of Amazon." What happened next was nothing short of spectacular. Well known figures in the Cloud computing space such as John Arundel, Forrest Brazeal, Yan Cui started to have diverging opinions. Yan Cui is known for his serverless articles in medium and his blog. In an article published in lumigo.com titled “You are wrong about vendor lock-in” he wrote: The biggest misconception about serverless vendor lock-in arguments is that technology choices are never lock-ins. Being “locked in” implies that there is no escape, but that's not the case with technology choices. Not with serverless, not with databases, not with frameworks, not with programming languages. Instead, technology choices create coupling, and no matter the choices you make, your solution will always be coupled to something. Moving away from those technologies requires time and effort, but there is always a way out. I'm your host Kassandra Russel, and today we are going to discuss serverless architectures. We will examine arguments for and against this technology. Next, we will discuss architectures, triggers, and use cases for serverless. Most importantly, we will discuss how to get your serverless functions productionized. This episode is the first part of a series about Serverless; more topics will be discussed in the next episodes. If you are thinking about adopting serverless or if you are already using it, this episode will give you useful insights, so stay tuned. Computing started with bare metal servers, then with virtual machines and later with containers and distributed systems. However, in 2006 a product called Zimki offered the first functions as a Service. This allowed a “pay as you go” model for code execution. Zimki was not commercially successful, but it paved the way for a new business model for computing services. Because of Zimki Functions as a Service or FaaS became a new category in the cloud space. In 2008, Google offered Google App Engine, App Engine allowed “metered billing” for applications. This new offering from Google allowed developers to create functions using a custom Python Framework. The limitation of this is glaringly obvious, developers were not able to execute arbitrary code. In November of 2014, AWS officially announced AWS Lambda. A fully-fledged Functions as a Service Platform that allowed the execution of arbitrary code. In our DevOps weekly newsletter, Shipped, we curate must-read serverless tutorials, news, and stories. Each week, there are tons of articles published, we read them for you, choose the best ones and share them with you. You can subscribe to Shipped by visiting faun.dev/join. --- Send in a voice message: https://anchor.fm/thedevopsfauncast/message Support this podcast: https://anchor.fm/thedevopsfauncast/support

We are in strange and uncertain times. The technology industry has always managed to respond to strange and uncertain times with incredible innovations that lead to the next round of growth. Growth that often comes with much higher rewards and leaves the world in a state almost unimaginable in previous iterations. The last major inflection point for the Internet, and computing in general, was when the dot come bubble burst.  The companies that survived that time in the history of computing and stayed true to their course sparked the Web 2.0 revolution. And their shareholders were rewarded by going from exits and valuations in the millions in the dot com era, they went into the billions in the Web 2.0 era. None as iconic as Google. They finally solved how to make money at scale on the Internet and in the process validated that search was a place to do so. Today we can think of Google, or the resulting parent Alphabet, as a multi-headed hydra. The biggest of those heads includes Search, which includes AdWords and AdSense. But Google has long since stopped being a one-trick pony. They also include Google Apps, Google Cloud, Gmail, YouTube, Google Nest, Verily, self-driving cars, mobile operating systems, and one of the more ambitious, Google Fiber. But how did two kids going to Stanford manage to become the third US company to be valued at a trillion dollars? Let's go back to 1998. The Big Lebowski, Fear and Loathing in Las Vegas, There's Something About Mary, The Truman Show, and Saving Private Ryan were in the theaters. Puff Daddy hadn't transmogrified into P Diddy. And Usher had three songs in the Top 40. Boyz II Men, Backstreet Boys, Shania Twain, and Third Eye Blind couldn't be avoided on the airwaves. They're now pretty much relegated to 90s disco nights. But technology offered a bright spot. We got the first MP3 player, the Apple Newton, the Intel Celeron and Xeon, the Apple iMac, MySQL, v.90 Modems, StarCraft, and two Stanford students named Larry Page and Sergey Brin took a research project they started in 1996 with Scott Hassan, and started a company called Google (although Hassan would leave Google before it became a company).  There were search engines before Page and Brin. But most produced search results that just weren't that great. In fact, most were focused on becoming portals. They took their queue from AOL and other ISPs who had springboarded people onto the web from services that had been walled gardens. As they became interconnected into a truly open Internet, the amount of diverse content began to explode and people just getting online found it hard to actually find things they were interested in. Going from ISPs who had portals to getting on the Internet, many began using a starting page like Archie, LYCOS, Jughead, Veronica, Infoseek, and of course Yahoo! Yahoo! Had grown fast out of Stanford, having been founded by Jerry Yang and David Filo. By 1998, the Yahoo! Page was full of text. Stock tickers, links to shopping, and even horoscopes. It took a lot of the features from the community builders at AOL. The model to take money was banner ads and that meant keeping people on their pages. Because it wasn't yet monetized and in fact acted against the banner loading business model, searching for what you really wanted to find on the Internet didn't get a lot of love. The search engines or portals of the day had pretty crappy search engines compared to what Page and Brin were building.  They initially called the search engine BackRub back in 1996. As academics (and the children of academics) they knew that the more papers that sited another paper, the more valuable the paper was. Applying that same logic allowed them to rank websites based on how many other sites linked into it. This became the foundation of the original PageRank algorithm, which continues to evolve today. The name BackRub came from the concept of weighting based on back links. That concept had come from a tool called RankDex, which was developed by Robin Li who went on to found Baidu.  Keep in mind, it started as a research project. The transition from research project meant finding a good name. Being math nerds they landed on "Google" a play on "googol", or a 1 followed by a hundred zeros. And within a year they were still running off University of Stanford computers. As their crawlers searched the web they needed more and more computing time. So they went out looking for funding and in 1998 got $100,000 from Sun Microsystems cofounder Andy Bechtolsheim. Jeff Bezos from Amazon, David Cheriton, Ram Shriram and others kicked in some money as well and they got a million dollar round of angel investment. And their algorithm kept getting more and more mature as they were able to catalog more and more sites. By 1999 they went out and raised $25 million from Kleiner Perkins and Sequoia Capital, insisting the two invest equally, which hadn't been done.  They were frugal with their money, which allowed them to weather the coming storm when the dot com bubble burst. They build computers to process data using off the shelf hardware they got at Fry's and other computer stores, they brought in some of the best talent in the area as other companies were going bankrupt.  They also used that money to move into offices in Palo Alto and in 2000 started selling ads through a service they called AdWords. It was a simple site and ads were text instead of the banners popular at the time. It was an instant success and I remember being drawn to it after years of looking at that increasingly complicated Yahoo! Landing page. And they successfully inked a deal with Yahoo! to provide organic and paid search, betting the company that they could make lots of money. And they were right. The world was ready for simple interfaces that provided relevant results. And the results were relevant for advertisers who could move to a pay-per-click model and bid on how much they wanted to pay for each click. They could serve ads for nearly any company and with little human interaction because they spent the time and money to build great AI to power the system. You put in a credit card number and they got accurate projections on how successful an ad would be. In fact, ads that were relevant often charged less for clicks than those that weren't. And it quickly became apparent that they were just printing money on the back of the new ad system. They brought in Eric Schmidt to run the company, per the agreement they made when they raised the $25 million and by 2002 they were booking $400M in revenue. And they operated at a 60% margin. These are crazy numbers and enabled them to continue aggressively making investments. The dot com bubble may have burst, but Google was a clear beacon of light that the Internet wasn't done for. In 2003 Google moved into a space now referred to as the Googleplex, in Mountain View California. In a sign of the times, that was land formerly owned by Silicon Graphics. They saw how the ad model could improved beyond paid placement and banners and acquired  is when they launched AdSense. They could afford to with $1.5 billion in revenue.  Google went public in 2004, with revenues of $3.2 billion. Underwritten by Morgan Stanley and Credit Suisse, who took half the standard fees for leading the IPO, Google sold nearly 20 million shares. By then they were basically printing money. By then the company had a market cap of $23 billion, just below that of Yahoo. That's the year they acquired Where 2 Technologies to convert their mapping technology into Google Maps, which was launched in 2005. They also bought Keyhole in 2004, which the CIA had invested in, and that was released as Google Earth in 2005. That technology then became critical for turn by turn directions and the directions were enriched using another 2004 acquisition, ZipDash, to get real-time traffic information. At this point, Google wasn't just responding to queries about content on the web, but were able to respond to queries about the world at large. They also released Gmail and Google Books in 2004. By the end of 2005 they were up to $6.1 billion in revenue and they continued to invest money back into the company aggressively, looking not only to point users to pages but get into content. That's when they bought Android in 2005, allowing them to answer queries using their own mobile operating system rather than just on the web. On the back of $10.6 billion in revenue they bought YouTube in 2006 for $1.65 billion in Google stock. This is also when they brought Gmail into Google Apps for Your Domain, now simply known as G Suite - and when they acquired Upstartle to get what we now call Google Docs.  At $16.6 billion in revenues, they bought DoubleClick in 2007 for $3.1 billion to get the relationships DoubleClick had with the ad agencies.  They also acquired Tonic Systems in 2007, which would become Google Slides. Thus completing a suite of apps that could compete with Microsoft Office. By then they were at $16.6 billion in revenues. The first Android release came in 2008 on the back of $21.8 billion revenue. They also released Chrome that year, a project that came out of hiring a number of Mozilla Firefox developers, even after Eric Schmidt had stonewalled doing so for six years. The project had been managed by up and coming Sundar Pichai. That year they also released Google App Engine, to compete with Amazon's EC2.  They bought On2, reCAPTCHA, AdMob, VOIP company Gizmo5, Teracent, and AppJet in 2009 on $23.7 Billion in revenue and Aardvark, reMail, Picnic, DocVerse, Episodic, Plink, Agnilux, LabPixies, BumpTop, Global IP Solutions, Simplify Media, Ruba.com, Invite Media, Metaweb, Zetawire, Instantiations, Slide.com, Jambool, Like.com, Angstro, SocialDeck, QuickSee, Plannr, BlindType, Phonetic Arts, and Widevine Technologies in 2010 on 29.3 billion in revenue. In 2011, Google bought Motorola Mobility for $12.5 billion to get access to patents for mobile phones, along with another almost two dozen companies. This was on the back of nearly $38 billion in revenue.  The battle with Apple intensified when Apple removed Google Maps from iOS 6 in 2012. But on $50 billion in revenue, Google wasn't worried. They released the Chromebook in 2012 as well as announcing Google Fiber to be rolled out in Kansas City.  They launched Google Drive They bought Waze for just shy of a billion dollars in 2013 to get crowdsourced data that could help bolster what Google Maps was doing. That was on 55 and a half billion in revenue.  In 2014, at $65 billion in revenue, they bought Nest, getting thermostats and cameras in the portfolio.  Pichai, who had worked in product on Drive, Gmail, Maps, and Chromebook took over Android and by 2015 was named the next CEO of Google when Google restructured with Alphabet being created as the parent of the various companies that made up the portfolio. By then they were up to 74 and a half billion in revenue. And they needed a new structure, given the size and scale of what they were doing.  In 2016 they launched Google Home, which has now brought AI into 52 million homes. They also bought nearly 20 other companies that year, including Apigee, to get an API management platform. By then they were up to nearly $90 billion in revenue. 2017 saw revenues rise to $110 billion and 2018 saw them reach $136 billion.  In 2019, Pichai became the CEO of Alphabet, now presiding over a company with over $160 billion in revenues. One that has bought over 200 companies and employs over 123,000 humans. Google's mission is “to organize the world's information and make it universally accessible and useful” and it's easy to connect most of the acquisitions with that goal. I have a lot of friends in and out of IT that think Google is evil. Despite their desire not to do evil, any organization that grows at such a mind-boggling pace is bound to rub people wrong here and there. I've always gladly using their free services even knowing that when you aren't paying for a product, you are the product. We have a lot to be thankful of Google for on this birthday. As Netscape was the symbol of the dot com era, they were the symbol of Web 2.0. They took the mantle for free mail from Hotmail after Microsoft screwed the pooch with that.  They applied math to everything, revolutionizing marketing and helping people connect with information they were most interested in. They cobbled together a mapping solution and changed the way we navigate through cities. They made Google Apps and evolved the way we use documents, making us more collaborative and forcing the competition, namely Microsoft Office to adapt as well. They dominated the mobility market, capturing over 90% of devices. They innovated cloud stacks. And here's the crazy thing, from the beginning, they didn't make up a lot. They borrowed the foundational principals of that original algorithm from RankDex, Gmail was a new and innovative approach to Hotmail, Google Maps was a better Encarta, their cloud offerings were structured similar to those of Amazon. And the list of acquisitions that helped them get patents or talent or ideas to launch innovative services is just astounding.  Chances are that today you do something that touches on Google. Whether it's the original search, controlling the lights in your house with Nest, using a web service hosted in their cloud, sending or receiving email through Gmail or one of the other hundreds of services. The team at Google has left an impact on each of the types of services they enable. They have innovated business and reaped the rewards. And on their 22nd birthday, we all owe them a certain level of thanks for everything they've given us. So until next time, think about all the services you interact with. And think about how you can improve on them. And thank you, for tuning in to this episode of the history of computing podcast. 

Spring est un framework du début des années 2000 pour faciliter le développement d'une application Java. Mais depuis le début des années 2000, bien des choses ont changé dans notre manière d'exécuter nos applications. L'apparition de Spring boot en 2014 a encore rendu plus simple la création d'une application autonome.La façon dont les applications tournaient dans les années 2000, puis 2010, a encore considérablement changé ces dernières années. Il y a d'abord eu l'avènement du cloud, avec Heroku, Cloud Foundry et Google App Engine, puis des conteneurs et de Kubernetes, sans oublier les fonctions... Chaque environnement d'exécution a ses particularités et ses spécificités qui sont autant de challenges pour le développement d'un framework.Parce que Java est un langage populaire, et que l'exécution d'applications Java est tout autant une préoccupation des devs que des ops, j'ai tenu à faire une série sur les défis de Java et du cloud natif. Pour commencer cette série, j'ai le plaisir de recevoir Stéphane Nicoll. Stéphane est software engineer pour VMware depuis le rachat de Pivotal par ce dernier, où il s'occupe activement du développement de Spring boot. Avec lui, je discute de l'évolution de Java, de Spring, des Buildpacks et de bien d'autres sujets passionnants !Support the show (https://www.patreon.com/electromonkeys)

What do organisations and IT departments really need in order to digitally transform and be competitive? Buzzwords and benefits are bandied around but as-a-Service is suffering from a serious lack of clarity! Michael Bird untangles the radical aaS revolution - a journey that starts with Salesforce, makes a few stops on the hybrid cloud highway, and culminates on the precipice of the digital age. We tackle cloud architecture and infrastructure with Paul Kennedy, to explore how you can get the best of both worlds and achieve the perfect trifecta: scalability, simplicity, and speed. Scott Thomson and Reuben Melville explain the new consumption model, from agility to utility billing. Plus, Tony Clement discusses the challenges organisations are facing to stay innovative and competitive, and why real transformation comes from within.

Depuis ses origines, le cloud a pour vocation de faciliter l'expérience des développeurs en leur permettant de déployer leurs applications simplement et en gérant pour eux la complexité du run. Quand nous pensons à cette simplicité, Heroku, Cloud Foundry ou Google App Engine nous viennent directement à l'esprit. Mais le cloud a un autre visage, composé d'instances de machines virtuelles, de VPC, de firewalls et de load balancers. Ces composants sont généralement complexes et ont souvent tendance a rebuter le premier développeur venu.C'est pour cette raison que les conteneurs ont pris un tel essor ces dernières années : ils permettent aux développeurs de déployer rapidement leurs applications en s'abstrayant de la complexité de l'infrastructure. Cependant, pour gérer ces conteneurs, il faut un orchestrateur, et cet orchestrateur, c'est aujourd'hui Kubernetes. Et Kubernetes est lui aussi une pièce d'infrastructure que les développeurs ne souhaitent pas gérer. C'est pourquoi Google a lancé Cloud Run : il réuni à lui seul la simplicité d'App Engine avec la flexibilité qu'offre les conteneurs. Dans cet épisode, j'ai le plaisir de recevoir Steren Giannini. Steren est product manager pour Google Cloud Platform, et il a eu la chance de travailler aussi bien sur App Engine que sur Cloud Run. Avec lui, nous allons découvrir les défis que Cloud Run vient relever et pourquoi il constitue la plateforme idéale pour déployer vos applications.Support the show (https://www.patreon.com/electromonkeys)

Saad Malik talks about building a free cover letter analysis tool that uses NLP with Flask and Python. It's deployed on Google App Engine.

Nick é programador Senior e ajudou a lançar o Google App Engine, o @Filipe Deschamps é destaque no Github e empresas congelando contratações.

En este especial converse con 3 de los voluntarios que participaron en el Hackaton de @CodeforVenezuela en San Francisco, del 14 al 16 de Febrero.  En este Hackaton 100+ participantes trabajaron para crear soluciones de visualización de data para una ONG Venezolana llamada Medicos por la Salud.  En esta ocasión converse con: Jose Montes de Oca: Cofundador y CTO de Newslit, Xoogler (Fue el 1er ingeniero que Google contrato para el Google App Engine), Programador estrella y Guaro Rajao. Fabiola Rosato: Ingeniera de Software y especialista en Robotica. Programadora en 2K (Los creadores de Bioshock). Cuando no esta programando, esta tocando el Ukulele. Luis Noguera: Analista de Negocios en Vivino, Alumni del Hult International Business School. Cuando no esta analizando modelos en R publica su música en Spotify.  Pueden apoyar el podcast en Patreon.com/ConexionesPodcast donde tenemos Q&As, Tutoriales de carrera y nuestra comunidad de Slack  Aprende mas sobre Code for Venezuela en y apoyalos via OpenCollective

En este especial converse con 3 de los voluntarios que participaron en el Hackaton de @CodeforVenezuela en San Francisco, del 14 al 16 de Febrero.  En este Hackaton 100+ participantes trabajaron para crear soluciones de visualización de data para una ONG Venezolana llamada Medicos por la Salud.  En esta ocasión converse con: Jose Montes de Oca: Cofundador y CTO de Newslit, Xoogler (Fue el 1er ingeniero que Google contrato para el Google App Engine), Programador estrella y Guaro Rajao. Fabiola Rosato: Ingeniera de Software y especialista en Robotica. Programadora en 2K (Los creadores de Bioshock). Cuando no esta programando, esta tocando el Ukulele. Luis Noguera: Analista de Negocios en Vivino, Alumni del Hult International Business School. Cuando no esta analizando modelos en R publica su música en Spotify.  Pueden apoyar el podcast en Patreon.com/ConexionesPodcast donde tenemos Q&As, Tutoriales de carrera y nuestra comunidad de Slack  Aprende mas sobre Code for Venezuela en y apoyalos via OpenCollective

En este especial converse con 3 de los voluntarios que participaron en el Hackaton de @CodeforVenezuela en San Francisco, del 14 al 16 de Febrero.  En este Hackaton 100+ participantes trabajaron para crear soluciones de visualización de data para una ONG Venezolana llamada Medicos por la Salud.  En esta ocasión converse con: Jose Montes de Oca: Cofundador y CTO de Newslit, Xoogler (Fue el 1er ingeniero que Google contrato para el Google App Engine), Programador estrella y Guaro Rajao. Fabiola Rosato: Ingeniera de Software y especialista en Robotica. Programadora en 2K (Los creadores de Bioshock). Cuando no esta programando, esta tocando el Ukulele. Luis Noguera: Analista de Negocios en Vivino, Alumni del Hult International Business School. Cuando no esta analizando modelos en R publica su música en Spotify.  Pueden apoyar el podcast en Patreon.com/ConexionesPodcast donde tenemos Q&As, Tutoriales de carrera y nuestra comunidad de Slack  Aprende mas sobre Code for Venezuela en y apoyalos via OpenCollective

En este especial converse con 3 de los voluntarios que participaron en el Hackaton de @CodeforVenezuela en San Francisco, del 14 al 16 de Febrero.  En este Hackaton 100+ participantes trabajaron para crear soluciones de visualización de data para una ONG Venezolana llamada Medicos por la Salud.  En esta ocasión converse con: Jose Montes de Oca: Cofundador y CTO de Newslit, Xoogler (Fue el 1er ingeniero que Google contrato para el Google App Engine), Programador estrella y Guaro Rajao. Fabiola Rosato: Ingeniera de Software y especialista en Robotica. Programadora en 2K (Los creadores de Bioshock). Cuando no esta programando, esta tocando el Ukulele. Luis Noguera: Analista de Negocios en Vivino, Alumni del Hult International Business School. Cuando no esta analizando modelos en R publica su música en Spotify.  Pueden apoyar el podcast en Patreon.com/ConexionesPodcast donde tenemos Q&As, Tutoriales de carrera y nuestra comunidad de Slack  Aprende mas sobre Code for Venezuela en y apoyalos via OpenCollective

Welcome to the History of Computing Podcast, where we explore the history of information technology. Because by understanding the past prepares us for the innovations of the future! Today we're going to look at the emergence of the cloud. As with everything evil, the origin of the cloud began with McCarthyism. From 1950 to 1954 Joe McCarthy waged a war against communism. Wait, wrong McCarthyism. Crap. After Joe McCarthy was condemned and run out of Washington, **John** McCarthy made the world a better place in 1955 with a somewhat communistic approach to computing. The 1950s were the peak of the military industrial complex. The SAGE air defense system needed to process data coming in from radars and perform actions based on that data. This is when McCarthy stepped in. John, not Joe. He proposed things like allocating memory automatically between programs, quote “Programming techniques can be encouraged which make destruction of other programs unlikely” and modifying FORTRAN to trap programs into specified areas of the storage. When a person loading cards or debugging code, the computer could be doing other things. To use his words: “The only way quick response can be provided at a bearable cost is by time-sharing. That is, the computer must attend to other customers while one customer is reacting to some output.” He posited that this could go from a 3 hour to day and a half turnaround to seconds. Remember, back then these things were huge and expensive. So people worked shifts and ran them continuously. McCarthy had been at MIT and Professor Fernando Corbato from there actually built it between 1961 and 1963. But at about the same time, Professor Jack Dennis from MIT started doing about the same thing with a PDP-1 from DEC - he's actually probably one of the most influential people many I talk to have never heard of. He called this APEX and hooked up multiple terminals on TX-2. Remember John McCarthy? He and some students actually did the same thing in 1962 after moving on to become a professor at Stanford. 1965 saw Alan Kotok sell a similar solution for the PDP-6 and then as the 60s rolled on and people in the Bay Area got really creative and free lovey, Cobato, Jack Dennis of MIT, a team from GE, and another from Bell labs started to work on Multics, or Multiplexed Information and Computing Service for short, for the GE-645 mainframe. Bell Labs pulled out and Multics was finished by MIT and GE, who then sold their computer business to Honeywell so they wouldn't be out there competing with some of their customers. Honeywell sold Multics until 1985 and it included symmetric multiprocessing, paging, a supervisor program, command programs, and a lot of the things we now take for granted in Linux, Unix, and macOS command lines. But we're not done with the 60s yet. ARPAnet gave us a standardized communications platform and distributed computing started in the 60s and then became a branch of computer science later in the late 1970s. This is really a software system that has components stored on different networked computers. Oh, and Telnet came at the tail end of 1969 in RFC 15, allowing us to remotely connect to those teletypes. People wanted Time Sharing Systems. Which led Project Genie at Berkely, TOPS-10 for the PDP-10 and IBM's failed TSS/360 for the System 360. To close out the 70s, Ken Thompson, Dennis Ritchie, Doug McIllroy, Mike Lesk, Joe Assana, and of course Brian Kernighan at Bell Labs hid a project to throw out the fluff from Multics and build a simpler system. This became Unix. Unix was originally developed in Assembly but Ritchie would write C in 72 and the team would eventually refactor Unix in C. Pretty sure management wasn't at all pissed when they found out. Pretty sure the Uniplexed Information and Computing Services, or eunuchs for short wasn't punny enough for the Multics team to notice. BSD would come shortly thereafter. Over the coming years you could create multiple users and design permissions in a way that users couldn't step on each others toes (or more specifically delete each others files). IBM did something interesting in 1972 as well. They invented the Virtual Machine, which allowed them to run an operating system inside an operating system. At this point, time sharing options were becoming common place in mainframes. Enter Moore's Law. Computers got cheaper and smaller. Altair and hobbyists became a thing. Bill Joy ported BSD to Sun workstations in 77. Computers kept getting smaller. CP/M shows up on early microcomputers at about the same time up until 1983. Apple arrives on the scene. Microsoft DOS appears in 1981 and and In 1983, with all this software you have to pay for really starting to harsh his calm, Richard Stallman famously set out to make software free. Maybe this was in response to Gates' 1976 Open Letter to Hobbyists asking pc hobbyists to actually pay for software. Maybe they forgot they wrote most of Microsoft BASIC on DARPA gear. Given that computers were so cheap for a bit, we forgot about multi-user operating systems for awhile. By 1991, Linus Torvalds, who also believed in free software, by then known as open source, developed a Unix-like operating system he called Linux. Computers continued to get cheaper and smaller. Now you could have them on multiple desks in an office. Companies like Novell brought us utility computers we now refer to as servers. You had one computer to just host all the files so users could edit them. CERN gave us the first web server in 1990. The University of Minnesota gave us Gopher in 1991. NTP 3 came in 1992. The 90s also saw the rise of virtual private networks and client-server networks. You might load a Delphi-based app on every computer in your office and connect that fat client with a shared database on a server to, for example, have a shared system to enter accounting information into, or access customer information to do sales activities and report on them. Napster had mainstreamed distributed file sharing. Those same techniques were being used in clusters of servers that were all controlled by a central IT administration team. Remember those virtual machines IBM gave us: you could now cluster and virtualize workloads and have applications that were served from a large number of distributed computing systems. But as workloads grew, the fault tolerance and performance necessary to support them became more and more expensive. By the mid-2000s it was becoming more acceptable to move to a web-client architecture, which meant large companies wouldn't have to bundle up software and automate the delivery of that software and could instead use an intranet to direct users to a series of web pages that allowed them to perform business tasks. Salesforce was started in 1999. They are the poster child for software as a service and founder/CEO Marc Benioff coined the term platform as a service, allowing customers to build their own applications using the Salesforce development environment. But it wasn't until we started breaking web applications up and developed methods to authenticate and authorize parts of them to one another using technologies like SAML, introduced in 2002) and OAuth (2006) that we were able to move into a more micro-service oriented paradigm for programming. Amazon and Google had been experiencing massive growth and in 2006 Amazon created Amazon Web Services and offered virtual machines on demand to customers, using a service called Elastic Compute Cloud. Google launched G Suite in 2006, providing cloud-based mail, calendar, contacts, documents, and spreadsheets. Google then offered a cloud offering to help developers with apps in 2008 with Google App Engine. In both cases, the companies had invested heavily in developing infrastructure to support their own workloads and renting some of that out to customers just… made sense. Microsoft, seeing the emergence of Google as not just a search engine, but a formidable opponent on multiple fronts also joined into the Infrastructure as a Service as offering virtual machines for pennies per minute of compute time also joined the party in 2008. Google, Microsoft, and Amazon still account for a large percentage of cloud services offered to software developers. Over the past 10 years the technologies have evolved. Mostly just by incrementing a number, like OAuth 2.0 or HTML 5. Web applications have gotten broken up in smaller and smaller parts due to mythical programmer months meaning you need smaller teams who have contracts with other teams that their service, or micro-service, can specific tasks. Amazon, Google, and Microsoft see these services and build more workload specific services, like database as a service or putting a REST front-end on a database, or data lakes as a service. Standards like OAuth even allow vendors to provide Identity as a service, linking up all the things. The cloud, as we've come to call hosting services, has been maturing for 55 years, from shared compute time on mainframes to shared file storage space on a server to very small shared services like payment processing using Stripe. Consumers love paying a small monthly fee for access to an online portal or app rather than having to deploy large amounts of capital to bring in an old-school JDS Uniphase style tool to automate tasks in a company. Software developers love importing an SDK or calling a service to get a process for free, allowing developers to go to market much faster and look like magicians in the process. And we don't have teams at startups running around with fire extinguishers to keep gear humming along. This reduces the barrier to build new software and apps and democratizes software development. App stores and search engines then make it easier than ever to put those web apps and apps in front of people to make money. In 1959, John McCarthy had said “The cooperation of IBM is very important but it should be to their advantage to develop this new way of using a computer.” Like many new philosophies, it takes time to set in and evolve. And it takes a combination of advances to make something so truly disruptive possible. The time-sharing philosophy gave us Unix and Linux, which today are the operating systems running on a lot of these cloud servers. But we don't know or care about those because the web provides a layer on top of them that obfuscates the workload. Much as the operating system obfuscated the workload of the components of the system. Today those clouds obfuscate various layers of the stack so you can enter at any part of the stack you want whether it's a virtual computer or a service or just to consume a web app. And this has lead to an explosion of diverse and innovative ideas. Apple famously said “there's an app for that” but without the cloud there certainly wouldn't be. And without you, my dear listeners, there wouldn't be a podcast. So thank you so very much for tuning into another episode of the History of Computing Podcast. We're lucky to have you. Have a great day!

An airhacks.fm conversation with Emmanuel Bernard (@emmanuelbernard) about: Amstrad PC 1512, the first PC computer ever made by Amstrad, two floppies are better than a hard drive, deleting double dots, C/PM OS, BIOS as cheating detection, creating snake game in BASIC, playing with Turbo Pascal, from GO TOs over loops to procedures, objects, aspects to functional programming, exploring Mandrake Linux, Tibco Messaging and C++, killing yourself with casting, the C discipline checker - an enforced linter, 120 errors caused by Coke break, no version control -- no time machine, starting with Java 1.2, replacing buttons with images in Swing / AWT, memory leaks in Java UI, creating ASP websites for fnac, building shopping cart with VB, going back with Visual Basic debugger, exploring Java as C# alternative, WebSphere vs. WebLogic, WebLogic was the JBoss of early 2000's, Apache Excalibur container, editing TopLink files with Eclipse IDE, replacing TopLink with early Hibernate, providing Hibernate support, the Rational Unified Process Workbench, hacking the organization is important, the gradient from hacking to politics, JOnAS was big in France, translating Hibernate documentation, patching Hibernate via CVS and email, Gavin King, Oracle and annotations as XML replacement, xdoclet was a great EJB annotation PoC, Cedric Beust created XDoclet, early Apache Geronimo participation, a French engineer will only tell you what you can do better, XML mapping with deeply nested annotations as prototype, EJB 3 specification comprised the component model and the persistence, Eclipse IDE was late with annotation support, working on EntityManager API with Bill Burke, joining forces with Java Data Objects (JDO) to participate on JPA, switching from fnac to JBoss, the first day at JBoss, Gaving King and Christian Bauer were Hibernate consultants, Steve Ebersole worked on Hibernate Core and Max Andersen on Eclipse tooling, Gavin King implemented an early bean validation prototype and Emmanuel took it over, contributing to a mature opensource project is really hard, Google App Engine wanted to use Hibernate as persistence backend, then google decided to use datanucleus.org, Book Driven Development is better than Conference Driven Development, Emmanuel started OGM - the Object Grid Mapper, in NoSQL space the model is simpler, JSON-P or JSON-B can be used as replacement for JPA entities, JDBC is hard to use what explains the success of ORM products, RedHat acquired JBoss, the switch from 200 employee company to 2000 employees company, developer is king at RedHat, RedHat acquired JBoss right after the introduction of JPA, becoming an architect, debezium was started by Randall Hauch then continued by Gunnar Morling, creating architecture slides with Google Docs, throughput driven optimizations, with containers throughput becomes less important, Java was designed for throughput and not memory efficiency and startup time, openJDK team, middleware team at Redhat had conversations about the future of Java on containers, Kubernetes is your cluster manager, WildFly is the flagship and the integration point, Sanne Grinovero was behind optimizations, Java's metaspace was too high, Java is a highly dynamic environment and therefore hard to optimize, the Excelsior JET VM, GCJ, Project Maxwell, GraalVM and the compiler is written in Java, WildFly Swarm became Thorntail and was an attempt to make the runtime smaller, Java's memory usage is the real problem, Quarkus came with the idea to make all the optimization at build time, not runtime, Emmanuel started Quarkus with Jason Greene and Bob McWhirter, the very first line of Quarkus code was written in a pub, the Quarkus project name was Shamrock what was the name of the pub, 3 months time for a PoC, hibernate, CDI, JAX-RS and JDBC drivers had to be optimized for the MVP, June 2018 was the very beginning of Quarkus, the shamrock pub is located in Australia, docker containers are immutable and the WAR deployment does not fit into this model, ThornTail's hollow JARs separate the business logic from the architecture, one of the Quarkus inspirations is the Play framework, Hibernate Panache got the idea from Play persistence, wad.sh watches changes and redeploys WARs on-the-fly, QuarkEE makes Quarkus look like a Java EE application, Quarkus on GraalVM is the perfect storm, Jakarta EE is a good way to reset Java EE expectations, the j4k conference, Emmanuel Bernard on twitter: @emmanuelbernard, Emannuel's website: https://emmanuelbernard.com

On this week's episode, Steph and Chris talk about PR sizing, load testing (the weird way), and ponder the merits and pitfalls of personal style in code. They also discuss Hertz suing Accenture for undelivered software and the belief that engineers should talk to users! This one truly has something for everyone. prettier elm-format Query objects Prettier plugin-ruby Stop Coding and Start Drawing - Joël's post on drawing Server sent events WebSockets Copy as cURL Google App Engine HireFire Hertz & Accenture tweet summary

Dans cet épisode, Guillaume, Arnaud et Audrey reviennent sur les derniers rebondissements des drama de la tech : le futur de Jakarta EE, Amazon vs l’Open Source … Et bien sûr on discute aussi technique avec les actualités de Elastic, JHipster, Micronaut, et plein d’autres. Enregistré le 6 mai 2019 Téléchargement de l’épisode LesCastCodeurs-Episode–210.mp3 News Apache Software Foundation joins GitHub open source community Langages La passation de support sur OpenJDK 8 et 11 d’Oracle à Red Hat (bug fixes et security ne viendront plus d’Oracle, comme prévu) Support Docker dans Java 8 Baeldung propose plein d’articles sur Groovy avec des tutoriels sur des aspects variés des APIs proposées par le langage Oracle ne veut plus qu’on utilise javax. Mike Millinkovitch de la fondation Eclipse Article de Mark Little Le point de vue de Tomitribe Librairies Un nouveau framework de log… par Google Introducing Spring Cloud Circuit Breaker JHipster 6 est sorti Middleware Micronaut 1.1 released Elastic Stack 7.0.0 released Cloud Essayer Java 11 sur Google App Engine et Java 8 sur Google Cloud Functions GraalVM et Quarkus dispo sur Clever Cloud: GraalVM is here! How to use Quarkus Azure tombe pour quelques heures Web Sortie de Node.js 12 Svelte3 Native image lazy-loading for the web! Update Regarding Add-ons in Firefox Update Firefox to the latest release A Conspiracy To Kill IE6 Outillage Développement remote avec VSCode Architecture You Are Not Google Méthodologies Les projets ont besoin de héros 80% des commits fait par 20% de gens: ce sont les projets majoritaires sur GitHub Sécurité DockerHub hack et le risque sur les images Loi, société et organisation Rectificatif sur la bataille Elastic - AWS de l’épisode 208 avec l’aide de Fabien Baligand AWS : il regarde si tu as du succès et pouf il te bouffe La license anti abus du droit du travail en Chine RGPD : la CNIL prévient qu’elle sera désormais moins conciliante Defining a Distinguished Engineer Trou noir : l’ingénieure Katie Bouman qui a contribué à la photo est victime de cyberharcèlement Manifeste écologique des professionnel·le·s de l’informatique Outils de l’épisode Crowdcast Eclipse Che par Manuel Payet Rubrique débutant How to use the JavaScript console: going beyond console.log() Conférences Crowdcast Hack Commit Push à Paris le samedi 15 juin par Florent Biville Dégaine - un compte à rebours à deux faces Riviera Dev du 15 au 17 mai 2019 NCrafts les 16 et 17 mai 2019 Mix-it les 23 et 24 mai 2019 BestOfWeb les 6 et 7 juin 2019 DevFest Lille le 14 juin 2019 Voxxed Days Luxembourg les 20 et 21 juin 2019 Sunny Tech les 27 & 28 juin 2019 à Montpellier JugSummerCamp le 13 septembre 2019 - Le CfP est ouvert. DevFestNantes les 21 et 22 octobre 2019 - Le CfP est ouvert. Codeurs en Seine le 21 novembre 2019 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/wdquestion](https://lescastcodeurs.com/crowdcasting/) 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/  

GUEST BIO: Dave is a Software Developer who has been building web applications since using HTML tables for layout started to go out of style.  A background in classical design and computer systems technology has enabled him to roam between the worlds of design and development.  Dave hails from Ottawa, Canada where he works remotely for Test Double. EPISODE DESCRIPTION: Phil’s guest on today’s show is Dave Mosher.  He has a background in classic design and computer systems technology. Today, he works remotely for Test Double as a Software Developer. Dave has also held this position at Shopify and Pillar Technology. For several years, he ran his own consulting company DAVEMO. He specializes in producing high-performance front-end web architecture and is currently working on getting more deeply involved in coaching and mentoring. KEY TAKEAWAYS: (1.04) – So Dave, can I ask you to expand on that intro and tell us a little bit more about yourself? Dave started his IT career working as a designer. He started out just working with HTML and CSS. At first, he did a lot of desktop publishing work. But, he soon moved on to development, working with databases. (2.27) - How did you get into Test Double? When did that come about? Dave spent a few years working at a start-up in Saskatoon, Saskatchewan, doing Python app development on Google App Engine. During that time, he grew a lot and learned to wear lots of hats. That role ended and Dave found himself at a loose end. Around the same time, Kevin Baribeau, a fellow test dabbler, was also under-occupied. He got a job at a consultancy called Pillar Technology. So, Dave applied for a role there too and was hired as a remote consultant. During much of his time with Pillar Technology he worked directly with the guy who hired him, Justin Searls. He also came across Ted Kaufmann while working there. Within about two years, Justin and Ted left Pillar Technology and set up Test Double. Dave ended up working for them as a consultant and later as a full-time employee. It was Justin that helped him to learn TDD, how to write tests and introduced him to the realm of Agile software development. Dave says he learned more in the nine months he worked directly with Justin than he had in the previous five years. (4.53) – Can you please share a unique career tip with the I.T. career audience? Dave’s advice is not to chase technology if you are not happy in your current role. In all likeliness a shiny new piece of technology is not going to solve your problems. If you start chasing after shiny tech it usually ends in disappointment. Ultimately, technology is not really the source of the challenge you are looking for. Solving people’s problems is what brings job satisfaction. You don’t need to be using the latest technology to do that.  Phil asks if he is saying that you need to avoid the shiny penny syndrome. Dave confirms that is the case. Chasing after the latest tech is a trap that a lot of newcomers fall into. They tend to underestimate the human factors of software development. (7.09) – Can you tell us about your worst career moment? And what you learned from that experience. Before joining Double Test full time, Dave took a job with Shopify. He wanted to get away from using JavaScript and learn to use Ruby on Rails. Overall, it was a good move. He learned a lot while working there. But, it was also where his worst career moment took place. At the time, he was refactoring their asset pipeline. It was really slow, taking five minutes to run, so Dave re-tooled it. He did a good job and got the run time down to about 20 seconds. So, they rushed his enhancement out to production. That was a mistake, a big one. They ended up taking down the whole of Shopify for about 15 minutes. At the time, there were around 80,000 websites running on the platform, so it was a big deal. This incident taught Dave that if you are making a change to a big platform you need to be especially careful before proceeding. You have to slow things down a bit and vet everything in every possible environment. It is also important to keep your QA and production environments as closely aligned as possible. At the time, Shopify had not succeeded in doing that. Dave and the people he was working with had been lured into a false sense of security. When the enhancement test went green in the QA environment they, understandably, assumed it would work in production. Unfortunately, that is not what happened. (11.10) – What was your best career moment? For Dave, that was when he first started working for Double Test. At the time they were working on a contract for a very large firm. Like most large corporations, the work environment was incredibly restrictive and inflexible. They had lots of standards in place and hoops to jump through. It was impossible to work fast because Dave and his colleagues had virtually no autonomy. However, they did find a way around this. Working with one of the firm’s developers, who did a lot of API work, they were able to build a shim and their own tooling. This enabled them to work in isolation at the front end with the angular piece and JavaScript. That meant that they could work much faster. For everyone involved in coming up with this solution it was a great technical triumph. But, Dave took the most pleasure from the fact that they had been able to help the team lead they were working with to gain confidence and excel. They invested a lot of time and energy into coaching him and giving him personal encouragement. This included teaching him people skills, for example, how to avoid confrontations and not become defensive. By the end of their time together he was a completely different person. So much so that he actually said “you guys changed my life.” (13.50) – Can you tell us what excites you about the future of the IT industry and careers? The fact that the barrier to entry has been lowered significantly really excites Dave. Code boot camps are making the field of IT a lot more accessible. In particular those boot camps that have structured their courses so that you do not necessarily have to pay your tuition fees up front. Dave has also been involved in producing educational resources. He took what he was doing at work and replicated the processes via screencasts so that he could help and educate other people. It was wildly successful and Dave found that putting together the lessons helped to solidify his knowledge. So, the benefits were twofold. Both parties benefited. He has noticed that a lot more people are starting to do share their knowledge, recently, something he is very pleased to see. (17.10) – What drew you to a career in IT? Dave drifted into IT through design. But, to get involved in the back end he had to go back to school and complete a Computer Systems Technology diploma. It was the only way he could go from being a starving artist, so to speak, to making some real money. (17.36) – What is the best career advice you have ever received? That advice came from Justin. He was struggling to convince Dave that test-driven development was the way to go. Dave, like most developers, was used to starting with the code first, then thinking about tests. Justin knew, from experience, that he was right. But, when Dave did not listen he did not continue to badger him. Instead, he let him go his own way and discover the painful way that he was wrong and Justin was right. Test-driven development did work best. This experience taught Dave the value of allowing yourself the freedom to fail. He learned how to use his pain as a motivator. He still remembers how going down the wrong path feels, so stops and thinks more before choosing a course of action. Dave is also more inclined to listen to others than he was when he first started his career. (18.54) – If you were to begin your IT career again, right now, what would you do? Dave says that he would probably spend a lot more time working with relational databases. If you want to specialize, being a database admin, and understanding the nuts and bolts of PostgreSQL or Postgres is a great approach, right now. He would also get a better handle on data modeling. Developers have a tendency to start without the data. As a result, all too often, they end up painting themselves into a corner pretty quickly. (19.56) – What are you currently focusing on in your career? Right now, Dave wants to get more involved with mentoring. He wants to have more of an impact on people’s personal lives. Dave is currently figuring who the people in his community are so that he can make himself available to them and help others to level up. (20.39) – What is the number one non-technical skill that has helped you the most in your IT career? For Dave, that is his musical abilities. He plays piano, drums, bass, and guitar. Dave finds playing to be a good creative outlet and has noticed that there is a lot of crossover between musicality and IT. While playing music, you learn to pick up on patterns and how to improvise. This skill set is useful for IT professionals as well as musicians. Playing music with others sharpens your ability to spot where they are going and follow them or add to what they are doing. These skills are also useful in the workplace. (22.18) – Phil asks Dave to share a final piece of career advice with the audience. Dave’s parting piece of advice is - When you feel it's time to move on, reconsider. Usually, if you are at the end of your rope there will still be something you can do to reframe the engagement in a way that is positive. Adversity provides you with the chance to rise to the challenge and learn. So, when you are struggling, stop, think and see if you can solve the problem without necessarily changing companies. Only move on when you have considered things carefully and determined there is no way to fix the problem. BEST MOMENTS: (1.45) DAVE – "I was drawn to the web via the power of design." (3.05) DAVE – "Don't chase technology would be my number one career tip." (7.08) PHIL – "It's the right technology for the right solution as opposed to a specific technology." (10.45) DAVE – " Take a little bit more time than you think you need and try to vet all of the things that you're working on in every environment possible" (18.33) DAVE – "Allow yourself the freedom to fail." (22.23) DAVE – “When you feel like it's time to move on, reconsider.” CONTACT DAVE: Twitter: https://twitter.com/dmosher LinkedIn: https://www.linkedin.com/in/dmosher/ Website: https://blog.davemo.com

Node.js is our topic this week as Mark and first-time host, Jon Foust, pick the brain of Myles Borins. Myles updates us on all the new things happening with Node.js, including the new .dev site that holds a ton of documentation to help people get started. Node.js now integrates with Cloud Build, the Node.js foundation has some new developments, and Google App Engine supports Node.js. The group has also been working on serverless containers. Myles Borins Myles Borins is a developer, musician, artist, and maker. They work for Google as a developer advocate serving the Node.js ecosystem. Myles cares about the open web and healthy communities. Cool things of the week Google Cloud Next ‘19 session guide now available blog Introducing scheduled snapshots for Compute Engine persistent disk blog Reliable task scheduling on Compute Engine with Cloud Scheduler site How to make a self-destructing VM on Google Cloud Platform article Making AI-powered speech more accessible—now with more options, lower prices, and new languages and voices blog Interview GCP Podcast Episode 105: Node.js with Myles Borins podcast Node.js site Introduction to Node.js site Nodejs.dev on Github site Cloud Build site Firebase site Node.js Foundation site JS Foundation site Linux Foundation site Foundation Bootstrap Team on Github site App Engine site G Suite site Apps Script site BigQuery site JSON site The hilarious misadventures of being a platform downstream from your language video Node.js Versions - How Do They Work? video Open Source Leadership Summit site Black Girls Code site Scripted site Girls Who Code site Question of the week How do I get google cloud APIs to work within Unity? Add packages from NuGet to a Unity project and read more in the Unity docs here Where can you find us next? Mark will be at GDC in March, Cloud NEXT, and ECG in April. Jon will be at GDC, Cloud NEXT, ECG, and Vector 2019.

An airhacks.fm conversation with Ondrej Mihályi about: starting programming with Logo, Pascal, C, Pentium 386, Scratch, minecraft, delphi and Java, pointers and destructors, participating in programming competitions, learning programming with Java, GWT, JSF and Primefaces over GWT, Eclipse, NetBeans, Java EE 5 introduced Dependency Injection (DI), Nitra is the oldest City in Slovakia, "Enterprise needs to be complicated", code generation with xdoclet in J2EE, simplifications with Java EE 5 in 2006, starting at Payara, running a JUG in Prague, Sun Grid Engine, serverless WARs, ideas for productive Clouds 2.0, serverless Java EE applications, early clouds with Google App Engine, Docker and Kubernetes for application packaging, making cloud services injectable, AWS lambdas are distributed commands, improving developer experience in the clouds with DI instead of singletons, Payara Source To Image (S2I) for server configuration in the clouds, separating the immutable servers from application logic with docker and clouds, cloud vendors are evaluating microprofile, repeatable and reproducible builds with Java EE in private clouds, Java EE deployment model became accidentally "cloud ready", with ThinWARs there is nothing to (security) scan, with ThinWARs there is no conceptual difference to lambda functions, cloud vendors participation in Jakarta EE, Payara is evaluating GraalVM and native compilation. Ondro's blog and @OndroMih / twitter.

Was muss man tun, um die Infrastruktur einer App ihrem schnellen Wachstum anzupassen und eine stabile Performance zu gewährleisten? In Folge 22 sprechen wir über Webserver, horizontale sowie vertikale Skalierung und Optimierungsansätze der Infrastruktur. Wir haben außerdem verschiedene Ansätze für euch, um mit mySQL eine gute Performance zu erreichen. Mit Firestore und noSQL-Lösungen runden wir diese Folge ab und erzählen euch mehr über die Google App Engine, der wir mit Quiz Planet immer wieder begegnen. Hier gibt's die Links zu den von uns besprochenen Technologien:Google App Engine Google Firestore redis cassandra als alternative Database TechnologiePicks of the Day: Fabi: Offline IMAP – ein cooles Tool zum Umziehen von E-Mails. Sebi: Kat Marchán (2017): Introducing npx: an npm package runner. Mario: CSS Stillleben Dennis: Netflix-Doku zum absurden Fyre Festival Schreibt uns! Schickt uns eure Themenwünsche und euer Feedback. podcast@programmier.bar Folgt uns! Bleibt auf dem Laufenden über zukünftige Folgen und Meetups und beteiligt euch an Community-Diskussionen. Twitter Instagram Facebook Besucht uns! Unser nächstes Meetup zu TypeScripts Typsystem mit Stefan Baumgartner findet am 26.02.19 statt. Hier anmelden!  Musik: Titeltrack von unserem Sound Designer Carlo: Programmierbar Intro Pick of the Day Track in voller Länge: Back to the von Hanimo Outro

第21回ジュビロ磐田メモリアルマラソン RUNART足の治療院-駒沢公園-「マラソンランナーのための次世代トータルサポート施設」 げんこつハンバーグの炭焼きレストランさわやか Heroku Now — Global Serverless Deployments Firebase Google App Engine Next.js zeit/pkg: Package your Node.js project into an executable zeit/hyper: A terminal built on web technologies Plans for the Next Iteration of Vue.js – The Vue Point – Medium Vue CLI

Vincent, Guillaume et Arnaud enfilent leur slip des cast codeurs par dessus leur pantalons pour vous parler d’AdoptOpenJDK, de Spring Boot, de Micronaut, de Kubernetes, de Google App Engine, des vieux pôts de l’écosystème java dans lesquels ont fait les meilleures soupes, de piscem vorat maior minorem et d’un long outil de l’épisode sur TestContainers. Enregistré le 6 novembre 2018 Téléchargement de l’épisode LesCastCodeurs-Episode–198.mp3 News Langages The AdoptOpenJDK Java 11 builds Présentations Java de Oracle Code One listées par Sharat Chandler Running Java code from the source, un article d’Andres Almiray montrant comment on peut lancer du code Java directement sans pré-compilation Focus sur les closures en JavaScript par Wassim Chegham qui continue sa série sur les bases de JavaScript Librairies Spring Boot 2.1.0 est sorti Micronaut 1.0 est sorti Présentation de Micronaut par Graeme Rocher à Oracle Code One et à Voxxed Days Microservices Tutoriel Micronaut sur InfoQ Tutoriel Micronaut sur Medium Infrastructure Kubernetes 1.12 (What’s new by Rancher) Comment dockeriser facilement des applis Java avec Jib (outil que nous avions couvert avec David Gageot) Cloud Github Actions: c’est un peu le IFTTT de Github pour le CI/CD, pour automatiser le workflow de développement Secrets in Serverless par Seth Vargo qui couvre différentes approches pour cacher des secrets (mots de passe, etc) quand on utilise des solutions Serverless . Node 10 sur Google App Engine sorti en beta en même temps que la release de Node 10 Go 1.11 sur Google App Engine également disponible en beta Data Redis modules forked pre-common clause. GoodFORM va-t’il (sur)vivre? MongoDB change sa licence pour tirer parti de la manne des installations cloud de MongoDB Le problème des licences avec Copyleft Outillage JVM Ecosystem Report 2018 - Quel est le plus gros concurrent à JenkinsCI ? Apache Maven 3.6.0 plus CI Friendly avec un usecase pour les releases incrémentales chez Jenkins Sécurité 50 millions de comptes compromis chez Facebook CERTFR–2018-ALE–011 - Vulnérabilité dans le client Git + Nombreux avis de sécurité sur CERT-FR Loi, société et organisation Publicis va acquérir Xébia France IBM va acquérir Red Hat VMware / Pivotal vont acquérir Heptio Outils de l’épisode TestContainers Rubrique débutant Apprendre Apache Maven, l’outil de gestion et d’automatisation de production des projets logiciels sur developpez.com (ou sur GitHub) Conférences DevFest Toulouse le 8 novembre 2018 - sold out. Bdx.io le 9 novembre 2018 - sold out. Devoxx Belgique du 12 au 16 novembre 2018 - sold out. DEVOPS D-DAY 2018 le 15 Novembre à Marseille. Codeurs en Seine le 22 novembre 2018. Snowcamp du 23 au 26 Janvier 2019. CfP DevFest Paris le 8 Février 2019 CfP ConFoo Montreal 2019 du 13 au 15 Mars 2019 CfP Greach (Madrid) du 28 au 30 Mars 2019 Le site du Paris JUG Le CFP de la soirée Young Blood VI 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/  

In this episode of the ARCHITECHT Show, Oren Teich, Google's director of product management for serverless, discusses how we evolved to a world of functions-as-a-service and how developers should think about using this new capability. Teich, who was previously COO at Heroku and whose product responsibilities include Google App Engine, also talks about the recent history of abstractions -- from IaaS to PaaS to containers -- including mistakes that were made, and why they're all still important tools.

Day two of NEXT was another day full of interesting interviews! Melanie and Mark sat down for quick chats with Haben Girma about accessibility in tech and Paresh Kharya to talk about NVIDIA. Next, we touched base with Amruta Gulanikar and Simon Zeltser to learn more about Windows SQL Server and .NET workloads on Google Cloud. The interviews wrap up with Henry Hsu & Isaac Wong of Holberton. Haben Girma The first Deafblind person to graduate from Harvard Law School, Haben Girma advocates for equal opportunities for people with disabilities. President Obama named her a White House Champion of Change. She received the Helen Keller Achievement Award, and a spot on Forbes 30 Under 30. Haben travels the world consulting and public speaking, teaching clients the benefits of fully accessible products and services. She’s a talented storyteller who helps people frame difference as an asset. She resisted society’s low expectations, choosing to create her own pioneering story. Haben is working on a book that will be published by Hachette in 2019. Paresh Kharya Paresh Kharya is Group Product Marketing Manager for data center products at NVIDIA responsible for product marketing of NVIDIA’s Tesla accelerated computing platform. Previously, Paresh held a variety of business roles in the high-tech industry, including group product manager at Adobe and business development manager at Tech Mahindra. Paresh has an MBA from the Indian Institute of Management and a bachelors of computer science and engineering from the National Institute of Technology, India. Amruta Gulanikar & Simon Zeltser Prior to joining Google Amruta spent 5+ years as a PM in the Office division at Microsoft working on many different products. Just before she left, she worked on launching a new service and supporting apps - “O365 Planner” which offers people a simple and visual way to organize teamwork. At Google, Amruta owns Windows on GCE which includes support for premium OS & Microsoft Server product images, platform improvements to support Windows workloads on GCE. Simon Zeltser is a Developer Programs Engineer at Google, working with .NET and Windows on Google Cloud Platform. Henry Hsu & Isaac Wong Henry Hsu is a software engineer trained at Holberton School. He has experience with C, C++, Python, Ruby/Rails, JavaScript, HTML/CSS, MySQL/Postgres, Unity, Game Maker Studio, Linux, Photoshop, 3D Studio Max, systems design, algorithms, and devops. Isaac Wong attends the Holberton School. He has a degree in horticulture from Texas A&M. Interviews Edge TPU site Cloud IoT Edge site Cloud Armor site Titan Security Key site Building on our cloud security leadership to help keep businesses protected blog Google Cloud Container Registry site Haben Girma’s website site Haben Girma’s presentation at NEXT video San Francisco Lighthouse for the Blind site National Federation of the Blind site National Association of the Deaf site NVIDIA site NVIDIA and Google Cloud Platform site Google Cloud Platform Podcast Episode 119 podcast Velostrata site GKE site Google App Engine site Stackdriver Debugger site Windows on Google Cloud Platform site SQL Server on Google Cloud Platform site .NET on Google Cloud Platform site Holberton School site Unity site GKE On-Prem site TensorFlow site Where can you find us next? We’ll both be at Cloud NEXT in Moscone West on the first floor, so come by and say hi! We have chocolate!

This week, Chris and Soroush talk about null, the billion dollar mistake. They talk about its past, its present and maybe even its future. Nice!enum Brain {     case small     case medium     case large     case galaxy     case universe }Liskov Substitution PrincipleNull References: The Billion Dollar MistakePython on Google App EnginePEP 484: Type HintsThe Definitive Reference To Why Maybe Is Better Than NullThat One Optional PropertyThe algebra (and calculus!) of algebraic data typesPoint-Free episode 4: Algebraic Data TypesOptional definitionSubEthaEdit

In this episode, Google Play Marketing is the customer of Google Cloud Platform. Melanie and Mark chat with Dom Elliott (Google Play) and Stewart Bryson (Red Pill Analytics) about how they use our big data processing and visualisation tools to introspect what is happening in the Google play ecosystem. Dom Elliott Dom Elliott leads global developer marketing communications for Google Play. His goal is to help Android app and game developers improve their app quality and business performance on Google Play, by raising awareness and understanding of features that can help them find success. Stewart Bryson Stewart Bryson is the Owner & Co-founder of Red Pill Analytics, a products and services company specializing in Cloud Analytics delivery. Red Pill is 4 years old and has about 30 employees in the US, UK and Brazil. We work with customers to accelerate their use of the public cloud for analytics, including migrating current on-premises workloads. Red Pill Analytics was engaged by Google Play to build the digital channel ingestion processes, as well as build all the Data Studio content for analyzing those channels. Cool things of the week Easy distributed training with TensorFlow using tf.estimator.train_and_evaluate on Cloud ML Engine blog CI/CD with Less Fluff & More Awesome blog 96 vCPU Compute Engine instances are now generally available announcement site Interview Google Play site Google Data Studio site docs Adding charts to Data Studio docs Google BigQuery Data Transfer Service site docs Google App Engine site docs Cloud Cloud PubSub site docs Cloud Functions site docs Google Cloud Pub/Sub Triggers docs tutorial Cloud Natural Language site docs Google Play Question of the week If you want to be able to unit test your integrations with Kubernetes with client-go, how can you mock what happens inside the cluster in your unit tests? fake.Clientset godoc code example testing.Fake godoc Where can you find us next? Melanie will be at Fat* in New York very shortly! Mark will be at the Game Developer's Conference | GDC in March.

This week, we dive into machine learning bias and fairness from a social and technical perspective with machine learning research scientists Timnit Gebru from Microsoft and Margaret Mitchell (aka Meg, aka M.) from Google. They share with Melanie and Mark about ongoing efforts and resources to address bias and fairness including diversifying datasets, applying algorithmic techniques and expanding research team expertise and perspectives. There is not a simple solution to the challenge, and they give insights on what work in the broader community is in progress and where it is going. Timnit Gebru Timnit Gebru works in the Fairness Accountability Transparency and Ethics (FATE) group at the New York Lab. Prior to joining Microsoft Research, she was a PhD student in the Stanford Artificial Intelligence Laboratory, studying computer vision under Fei-Fei Li. Her main research interest is in data mining large-scale, publicly available images to gain sociological insight, and working on computer vision problems that arise as a result, including fine-grained image recognition, scalable annotation of images, and domain adaptation. The Economist and others have recently covered part of this work. She is currently studying how to take dataset bias into account while designing machine learning algorithms, and the ethical considerations underlying any data mining project. As a cofounder of the group Black in AI, she works to both increase diversity in the field and reduce the impact of racial bias in the data. Margaret Mitchell M. Mitchell is a Senior Research Scientist in Google's Research & Machine Intelligence group, working on artificial intelligence. Her research involves vision-language and grounded language generation, focusing on how to evolve artificial intelligence toward positive goals. Margaret's work combines machine learning, computer vision, natural language processing, social media, and insights from cognitive science. Before Google, Margaret was a founding member of Microsoft Research's “Cognition” group, focused on advancing artificial intelligence, and a researcher in Microsoft Research's Natural Language Processing group. Cool things of the week GPS/Cellular Asset Tracking using Google Cloud IoT Core, Firestore and MongooseOS blog GPUs in Kubernetes Engine now available in beta blog Announcing Spring Cloud GCP - integrating your favorite Java framework with Google Cloud blog Interview PAIR | People+AI Research Initiative site FATE | Fairness, Accountability, Transparency and Ethics in AI site Fat* Conference site & resources Joy Buolamwini site Algorithmic Justice Leaguge site ProPublica Machine Bias article AI Ethics & Society Conference site Ethics in NLP Conference site FACETS site TensorFlow Lattice repo Sample papers on bias and fairness: Gender Shades: Intersectional Accuracy Disparities in Commercial Gender Classification paper Facial Recognition is Accurate, if You're a White Guy article Mitigating Unwanted Biases with Adversarial Learning paper Improving Smiling Detection with Race and Gender Diversity paper Fairness Through Awareness paper Avoiding Discrimination through Casual Reasoning paper Man is to Computer Programmer as Woman is to Homemaker? Debiasing Word Embeddings paper Satisfying Real-world Goals with Dataset Constraints paper Axiomatic Attribution for Deep Networks paper Monotonic Calibrated Interpolated Look-Up Tables paper Equality of Opportunity in Machine Learning blog Additional links: Bill Nye Saves the World Episode 3: Machines Take Over the World (includes Margaret Mitchell) site “We're in a diversity crisis”: Black in AI's founder on what's poisoning the algorithms in our lives article Using Deep Learning and Google Street View to Estimate Demographics with Timnit Gebru TWiML & AI podcast Security and Safety in AI: Adversarial Examples, Bias and Trust with Mustapha Cisse TWiML & AI podcast How we can build AI to help humans, not hurt us TED PAIR Symposium conference Question of the week “Is there a gcp service that's cloud identity-aware proxy except for a static site that you host via cloud storage?” Answer between Mark & KF Cloud Identity-Aware Proxy site & docs Cloud Storage site & docs Hosting a Static Website on Cloud Storage site Google App Engine site & docs weasel repo Where can you find us next? Melanie will be at Fat* in New York in Feb. Mark will be at the Game Developer's Conference | GDC in March.

This week my guests are Mark Mandel and Francesc Campoy Flores who run the Google Cloud Platform (GCP) Podcast. They produce a weekly podcast discussing everything on Google Cloud Platform that would benefit your business. As you look at alternatives like Microsoft Azure, Amazon Web Services, you should also look at Google Cloud Platform. Our conversation is super techy, but very informative. Listen to the interview and learn more about Google Cloud Platform Major Take-Aways From This Episode: The GCP Podcast interviews Google product managers and engineers who answer questions from listeners. Google’s philosophy of Open Cloud is explained. Google App Engine and managed services explained. Kubernetes and Container Orchestration (Google Container Engine) at scale - @ 16:00 Google Cloud is open as it is the best place to run Open Source technologies. No vendor lock-in; minimizing all operations that are not a part of your business. The concept of “Lift and Shift”. “On Demand” managed services - Helping customers orchestrate their projects in the Cloud and available to everyone. Open source product, Spinnaker – automated launcher for common things; Container builder – sets up steps of a workflow. Why you need a better observability of your system? Difference between “Go Programming”, “Python”, and “C++” @ 27:00. Who is Go Programming Language for? Code that is easy to learn for decision-makers. The direction the future programming talent is heading to. Other key resources:  TensorFlow  open-source machine learning framework  Greenfield Platform @ 8:00  Cloud Identity and Access Management (IAM)  - unified view into security policy across your entire organization, with built-in auditing to ease compliance processes.  Episode #25 on GCP Podcast, Interview with Go team members.  Episode #100 with Vint Cerf, one of Internet founders, on GCP podcast Read full transcript here. About Mark Mandel Mark Mandel is a Developer Advocate for the Google Cloud Platform. Hailing from Australia, Mark built his career developing backend web applications which included several widely adopted open source projects, and running an international conference in Melbourne for several years. Since then he has focused on becoming a polyglot developer, building systems in Go, JRuby and Clojure on a variety of infrastructures. In his spare time he plays with his dog, trains martial arts and reads too much fantasy literature. About Francesc Campoy Flores Francesc Campoy Flores is a Developer Advocate for Go and the Cloud at Google. He joined the Go team in 2012 and since then he has written some considerable didactic resources and traveled the world attending conferences, organizing live courses, and meeting fellow gophers. He joined Google in 2011 as a backend software engineer working mostly in C++ and Python, but it was with Go that he rediscovered how fun programming can be. Where to Find Google Cloud Platform Podcast Email: hello@gcppodcast.com Twitter: GCPPodcast Google Plus: +GCPPodcast Reddit: /r/gcppodcast Ways to connect with Mark and Francesc: Mark Mandel: Twitter Website LinkedIn Francesc Campoy Flores: Twitter Website LinkedIn This episode is sponsored by the CIO Innovation Insider Offense and Defense Community, dedicated to Business Digital Leaders who want to be a part of 20% of the planet and help their businesses win with innovation and transformation. Credits: * Outro music provided by Ben’s Sound Other Ways To Listen to the Podcast iTunes | Libsyn | Soundcloud | RSS | LinkedIn Leave a Review Feedback is my oxygen. I would appreciate your comments, so please leave an iTunes review here. Click here for instructions on how to leave an iTunes review if you're doing this for the first time. About Bill Murphy Bill Murphy is a world renowned Innovation and Transformation (Offense and Defense) Expert dedicated to your success as an IT business leader. Follow Bill on LinkedIn and Twitter.

Rui Ueyama さんをゲストに迎えて、CPU 脆弱性、トランスクリプト、日本語入力、ガジェット、HDR などについて話しました。 Show Notes Government shutdown 2018 Rebuild: 198: Gaming Hogehoge (drikin) Meltdown and Spectre How the industry-breaking Spectre bug stayed secret for seven months コンピュータセキュリティと様々なサイドチャネル攻撃｜Rui Ueyama Amazon: Intel Meltdown patch will slow down your AWS EC2 server Google claims its Spectre patch results in 'no degradation' to system performance Skyfall and Solace vulnerabilities Intel CES 2018 keynote: behind the scenes exclusive Mitigations landing for new class of timing attack | Mozilla Security Blog IPhone’s Rolling Shutter Captures Amazing ‘Slo-Mo’ Guitar String Vibrations Hash DoS Attack perl5180delta Rebuild Search Google Cloud Speech API Rebuild: Supporter Gboard 6.7 beta adds Chinese, Japanese support Chromecast and Google Homes reportedly overloading home Wi-Fi DNS-over-HTTPS NeverSSL - helping you get online badssl.com Heroku Postgres Google App Engine .fm TLD Chrome 63 forces .dev domains to HTTPS via preloaded HSTS Marques Brownlee (MKBHD) Google CEO Sundar Pichai says he does not regret firing James Damore Light | Camera Lytro Google Photos will limit Pixel 2 users' uploads after 2020 Amazon Echo Spot Alexa, go ahead and hand over recordings in murder case Black Mirror フィリップ・K・ディックのエレクトリック・ドリームズ Turing Complete FM

Deep Kapadia and JP Robinson from New York Times join Mark and Francesc to discuss how they use Google Cloud Platform to serve the New York Times to its readers. About JP Robinson JP Robinson maintains NYT's internal and open source tools and frameworks that are related to the Go programming language. He also lead backend development of NYT's games platform. Recently his team completely rewrote our backend with Go and GCP tools. In doing so they've managed to significantly lower request latencies and cut costs in half. About Deep Kapadia Deep Kapadia manages the Infrastructure and Delivery Engineering, Site Reliability and Test Automation teams at The New York Times. His teams are responsible for providing other engineering teams with tools and processes needed to get their jobs done on a day to day basis. His teams recently have been working on building the GKE deployment pipeline and enabling other teams to migrate to the Cloud from our physical datacenters and also moving their entire edge and routing caching architecture from internally hosted varnish to Fastly. They also helped move most of their site behind HTTPS. Cool things of the week Cutting cluster management fees on Google Kubernetes Engine blog Coming in 2018: GCP's Hong Kong region blog Introducing an easy way to deploy containers on Google Compute Engine virtual machines blog Interview New York Times Crossword site Moving The New York Times Games Platform to Google App Engine blog New York Times in 1996 webarchive Google App Engine site docs Cloud Datastore site docs Kubernetes Engine site docs Cloud Pub/Sub site docs Google BigQuery site docs Cloud Endpoints site docs Drone GAE github Drone GKE github Marvin github openapi2proto github gRPC site New York Time Open site Question of the week What best practices are there for securing a Kubernetes Engine Cluster? Precious cargo: Securing containers with Kubernetes Engine 1.8 blog Where can you find us next? Mark will be Montreal in December to speak at Montreal International Games Summit. Melanie will be at NIPS (Neural Information Processing Systems) in Long Beach and will also be attending Black in AI on December 8th.

Soroush interviews Chris about his experience writing Python at work over the past couple of months.Chris was wrong about something! Python is not pass-by-reference; see Is Python call-by-value or call-by-reference? Neither.Pyramid Web FrameworkGoogle App EnginePython 2 or Python 3Unicode in Python 2Uncle Bob - The Dark PathOur episode on Tests and Types (Patreon-only)“if you ignore uncle bob's terrible opinions on women, you can fully appreciate how terrible his opinions on software are” — @pasiphae_goalsmypy: “an experimental optional static type checker for Python”Truth Value Testing in Python (2.7)Soroush: Falsiness in SwiftPython Anti-Patterns: Using a mutable default value as an argumentPython List ComprehensionsStack Overflow discussion: Python List Comprehension vs MapPython Lambda FunctionsIs Python call-by-value or call-by-reference? Neither (Chris was wrong about this!)PEP-8: Style Guide for Python CodePEP-20: The Zen of PythonPEP-0: list of all PEPsGet a new Fatal Error episode every week by becoming a supporter at patreon.com/fatalerror.

Dan McGrath and Alex Dufetel join Francesc and Mark in the studio this week to discuss Cloud Firestore, the brand new, fully-managed NoSQL document database for mobile and web app development. About Dan McGrath Dan McGrath is the Product Manager for Cloud working on databases such as Cloud Firestore. Dan has spent the last decade working in product & engineering for large scale database systems. He has a background in banking software, databases, and information security. About Alex Dufetel Alex Dufetel is a Product Manager for the Firebase team at Google, working on Backend-as-Service products such as the Realtime Database and Cloud Firestore. Alex was previously Director of Products at Fuze, a video conferencing and enterprise communications provider and, before that, a co-founder of LiveMinutes, a real-time team collaboration app. Cool things of the week Extending per second billing in Google Cloud blog PHP 7.1 for Google App Engine is generally available blog Java 8 on App Engine standard environment is now generally available blog migration Kubernetes 1.8: Security, Workloads and Feature Depth blog Google Container Engine - Kubernetes 1.8 takes advantage of the cloud built for containers blog Announcing Cloud IoT Core public beta blog Interview Cloud Firestore announcement site docs Cloud Firestore server sdks docs Extend Cloud Firestore with Cloud Functions docs Cloud Firestore for Realtime Database Developers blog Firestore Discuss google-group Firestore Realtime Database site docs Question of the week How do I import/export data from my Cloud Datastore? Exporting and Importing Entities docs Scheduling an Export docs Where can you find us next? Francesc just released a new #justforfunc and he'll be presenting at Go Meetup London, Velocity London, Google Cloud Summit Paris and Devfest Nantes He is heading to Australia for GDG Devfest Melbourne and Game Connect Asia Pacific and will be hanging out at Unite Melbourne and PAX Australia.

Sourcegraph provides navigation tools for source code, and it's powered by Go and Google Cloud Platform. Quinn Slack, CEO and co-founder, joins your co-hosts Francesc and Mark to discuss how they built their features on top of our infrastructure. About Quinn Slack Quinn Slack is CEO and co-founder of Sourcegraph, code intelligence software that lets software teams ship better and faster. Prior to Sourcegraph, Quinn co-founded Blend, an enterprise technology company with over 150 employees dedicated to improving home lending. His long-term goal is to build the products and infrastructure to support the future world where billions of people have coding fluency (just as billions of people today can read and write). Cool things of the week Introducing managed SSL for Google App Engine announcement With Forseti, Spotify and Google release GCP security tools to open source community announcement Global Kubernetes in 3 Steps on GCP medium by Christopher Grant Interview Sourcegraph Sourcegraph source code GitHub Google Container Engine Helm GitHub GCPPodcast #50 Helm with Michelle Noorali and Matthew Butcher sourcegraph.com Question of the week How can I automatically redact Personally Identifiable Information (PII) or other sensitive information? Data Loss Prevention API docs Demo of Data Loss Prevention at Cloud Summit Sydney YouTube Where can you find us next? Francesc will be presenting at Google Cloud Summit in Chicago next week. In October, he'll be presenting at Velocity London, Google Cloud Summit Paris and Devfest Nantes Mark is attending Strangeloop in September. He is also heading to Australia in October for GDG Devfest Melbourne and Game Connect Asia Pacific and will be hanging out at Unite Melbourne and PAX Australia.

Francesc and Mark are joined this week by Lukas Karlsson from Broad Institute and Mike Altarace from Google Cloud Platform to discuss the Platinum Customer relationship with Google Cloud Platform. About Lukas Karlsson Lukas has been working at the Broad in various roles over the last fourteen years or so. He now run our cloud architecture and strategy and works in developer relations, advocating for the software developers who consume our services. About Mike Altarace Mike has been a Strategic Customer Engineer (SCE, pronounced Ski) assigned to the Broad Institute for over a year. He's been working with Broad on all manners of operating their GCP environment. All is on the table, technical issues, billing, shared events, certifications. Cool things of the week Google Cloud Platform now open in London blog gdpr Container Engine now runs Kubernetes 1.7 to drive enterprise-ready secure hybrid workloads blog Marvin is a go-kit server for Google App Engine github Google Container Builder Part 1 (Cloud Rolling Update) youtube podcast Interview Broad Institute site Google Cloud Storages home docs Pre-emptible Virtual Machines site docs Google Cloud Platinum Support support Customer Reliability Engineers podcast Gaining full control over your organization's cloud resources (Google Cloud Next ‘17) youtube Question of the week If I want to run a single node development Kubernetes cluster, and I don't want to pay for a Network LoadBalancer as well - how do I expose services? NodePort Services docs Configure a static IP for a Ingress Service docs Where can you find us next? Francesc will be at the July GoSF Meetup. Mark will be speaking at Pax Dev and then attending Pax West right after.

Wendy Kan joins your co-hosts Francesc and Mark today to talk about Kaggle, their competitions, and the cool data sets available on their platform. Kaggle joined the Google family a few months ago, so it's a great opportunity to know more about the platform and the amazing community behind it. About Wendy Kan Wendy is a data scientist at Kaggle, the largest global data science community. Wendy works with companies and organizations to transform their data into machine learning competitions and had launched over 50 competitions on various topics such as image classification, revenue prediction, GIS and satellite data, click through rate, customer categorization, and real estate prediction. She was a software engineer and researcher before joining Kaggle. She holds BS and MS degrees in Electrical Engineering from National Tsing Hua University and PhD in Biomedical Engineering from The University of Texas at Austin. Cool things of the week Google App Engine standard now supports Java 8 announcement How SREs find the landmines in a service - CRE life lessons blog post How HBO's Silicon Valley built “Not Hotdog” with mobile TensorFlow, Keras & React Native Hackernoon Interview Kaggle home page Kaggle Competitions list Kaggle Datasets list Tensorflow: An open-source software library for Machine Intelligence tensorflow.org Keras: The Python Deep Learning library keras.io Question of the week How do you do client side load balancing with gRPC and Kubernetes? Ray Tsang answers with a GitHub repo Where can you find us next? Francesc will be at GopherCon in Denver! Mark will be speaking at Google Cloud Summit, New York with Phoenix One Games in July.

Kubernetes makes it easier for engineering teams to manage their distributed systems architecture. But it’s still not simple to deploy and operate a Kubernetes cluster. Google Container Engine (GKE) is a managed control plane for Kubernetes. Just as developers can use Google App Engine to easily deploy monolithic apps against a platform as a service, The post Container Engines with David Aronchick and Chen Goldberg appeared first on Software Engineering Daily.

In this episode of Data Driven, Frank and Andy talk to Lynn Langit.  Lynn’s a triple threat: Microsoft MVP, Google Cloud Developer Expert, and AWS Community Hero.  Over one million people have watched her Hadoop Fundamentals online course.  We are honored to have Lynn on our show! Links Mentioned: Lynn’s Website (https://lynnlangit.com) Lynn’s LinkedIn Learning Page (https://www.linkedin.com/learning/instructors/lynn-langit) Genome Engineering Applications: Early Adopters of the Cloud (https://aws.amazon.com/blogs/aws/genome-engineering-applications-early-adopters-of-the-cloud/) XKCD WebComic: Listening (https://xkcd.com/1807/) Sponsor: Enterprise Data & Analytics (http://entdna.com?dd3) Cool Conversation Blurbs The Coding Architect and Lifelong Learner ([7:30]) Bio-informatics research ([10:50]) Opportunistic Learning ([21:15]) Algorithms run our day-to-day ([27:45]) The law and DNA ([31:45]) Unintended consequences ([36:53]) Hacking Exposed ([41:00]) Lynn Langit Bio Lynn Langit was a developer evangelist for the Microsoft MSDN team for the past 4 years.. Prior to working at Microsoft, she founded and served as lead architect of a development firm that created BI solutions. She holds a number of Microsoft certifications, including MCITP, MCSD, MCDBA, and MCT. Lynn left Microsoft to do consulting and training in October 2011. Lately she’s authored and taught for DevelopMentor (SQL Server 2012 and Google App Engine). Lynn’s been doing production work with SQL Server, .NET, Java and more. Her data blog is at www.LynnLangit.com. She is also the co-founder of the non-profit ‘Teaching Kids Programming’ – more at www.TeachingKidsProgramming.org.

This week, Mark and Francesc get a chance to talk directly to the Director of Customer Reliability Engineering himself, Luke Stone, all about CRE - where it came from, what it's goals are, and how it's been working with some big customers at Google Cloud Platform. About Luke Stone Luke is defining the customer experience of Google's new Customer Reliability Engineering (CRE) team. When he joined Google in 2002 he was the first technical support engineer for AdSense. He ran software engineering teams and started building on Google App Engine in 2009. Recently, he led the technical support team for Google Cloud Platform before becoming a founding member of the CRE team. Before Google, Luke was a system administrator and developer in academic and non-profit organizations, and studied computer science at Stanford. Cool things of the week Google Cloud announces Machine Learning Startup Competition blog Quantifying the performance of the TPU, our first machine learning chip blog DeepBreath: Preventing angry emails with machine learning blog github Interview Introducing Google Customer Reliability Engineering blog All the CRE blog posts blog Site Reliability Engineering book Postmortem Culture: Learning from Failure chapter Question of the week Rokesh Jankie returns this week, with another question: What does it mean to have 99.99% availability. That's not 100%, what does it mean for customers who have mission critical applications? SRE II with Paul Newson podcast High Availability wikipedia Borg and Kubernetes with John Wilkes podcast Where can you find us next? Mark is going to be at and then on to East Coast Games Conference and Vector in April. He's also going to be hosting the Playcrafting + Extra Life Game Jame & Game Fest, raising money for UCSF Benioff Children's Hospitals. Finally he'll be in Sweden for Nordic Games Conference as well. Francesc will be presenting at Gophercon China in April, and will then be at the New York Google Developer Group for a Serverless event! Francesc has also released a new Just for Func episode, covering the Context package!

Naoki Hiroshima さんをゲストに迎えて、ゼルダの伝説、4Kテレビ、バイリンガル、H1B, ソフトウェアエンジニアリング、教育、ラーメン、Alexa、Google Home, アドバタイジング、Snapchat などについて話しました。 Show Notes ゼルダの伝説　ブレス オブ ザ ワイルド | Nintendo リングにかけろ THE MAKING OF ゼルダの伝説 ブレス オブ ザ ワイルド [開発のはじまり] 任天堂、『ゼルダの伝説 BoW』の「エキスパンション・パス」発表 Sony X700D Review (XBR49X700D, XBR55X700D) Android TV BRAVIA meets Android TV™ 4k Movies List & Content Guide - Netflix, Amazon for UHD TVs 心肺停止 Samurai Gourmet Revenge of the Nerds (1984) US suspends expedited processing of H-1B visas Steve Bannon Suggests There Are Too Many Asian CEOs In Silicon Valley Breitbart gets to keep using Shopify to sell its merchandise Rebuild: 153: Connecting The Dots (rui314) Highest paying companies in Silicon Valley Cargo Cult programming Rebuild: 175: Executive Order (higepon) Marufuku Ramen 家系ラーメン カムデンズ ブルースタードーナツ カールスジュニア Carl’s Jr.® パンダエクスプレス Amazon.com: Alexa Skills Connect Google Assistant - IFTTT Google Home is playing audio ads for Beauty and the Beast Amazon pushes back on prosecutor request for Alexa smart speaker info Children's Online Privacy Protection Rule ("COPPA") Snapchat: How the Snap IPO Ended Up a Huge Flop How does Snapchat use Google App Engine?

Our beloved teammate Paul Newson is back from his SRE rotation to tell us about all the lessons that he learned during all these months. Your co-hosts, Mark and Francesc, are as always here to ask all the burning questions. About Paul Paul is an SRE Advocate at Google. As part of Google's Cloud developer relations team, he helps our customers understand reliability best practices based on his experiences working as a Site Reliability Engineer (SRE) on Google Compute Engine and as a Software Engineer on Google Cloud Storage. Before joining Google, he cofounded a tiny game technology startup, sold it to Microsoft, where he then worked on DirectX, Xbox, Xbox Live, and Forza Motorsport, before spending some time working on interesting machine learning problems in Microsoft Research. Outside of work he enjoys rock climbing, motorcycling, and other activities that demand complete focus. He doesn't often post on social media, but when he does, he does it at @newsons_nybbles. Cool thing of the week Fission: Serverless Functions as a Service for Kubernetes Kubernetes blog CRE Life Lessons blog post series The SRE book is now free! read it online Interview More episodes with Paul Newson: Storage with Paul Newson episode 14 Site Reliability Engineering episode 38 More links: The SRE book home page SLOs, SLIs, SLAs, oh my - CRE life lessons blog post A Google SRE explores GitHub reliability with BigQuery blog post Introducing Google Customer Reliability Engineering blog post Question of the week The question today comes from StackOverflow. How can I see which version of an App Engine service is the default? app.services/get docs Microservices Architecture on Google App Engine docs Were will we be? Mark will be at GDC and afterwards he'll be speaking at Cloud NEXT, both in San Francisco. Francesc is doing a European tour, after speaking at golab and GolangBCN he's currently in Paris and on his way to the Go Devroom at FOSDEM. A bit later he'll also be at Gophercon India.

In this episode I am joined by Terry Ryan, Developer Advocate at Google. Here we discuss the Google App Engine platform, what it is, and when it is a relevant solution to use for a major web application. A writeup to this episode can be found via https://www.thepolyglotdeveloper.com/2016/10/tpdp-episode-10-google-app-engine/ If you have questions that you'd like answered in the next episode, visit https://www.thepolyglotdeveloper.com/podcast-questions and fill out the form.

This week, Terry Ryan and Brent Shaffer join Francesc and guest host Chris Broadfoot to talk all about PHP on Google Cloud Platform About Terry Terry Ryan is a Developer Advocate for the Google Cloud Platform team. He has 15 years of experience working with the web - both front end and back. He is passionate about web standards and wants to bring web developers to the Google Cloud Platform. Before Google, he worked for Adobe and the Wharton School of Business. He also wrote Driving Technical Change for Pragmatic Bookshelf, a book that arms technology professionals with the tools to convince reluctant co-workers to adopt new tools and technology. About Brent Brent Shaffer is a Developer Programs Engineer at Google who is involved primarily in the Open Source world of PHP and Ruby. His most notable Open Source contribution is the OAuth2 server for PHP, and his favorite OpenSource project is the Symfony framework. Outside of work, he loves mountaineering and playing folk music in a band. Cool thing of the week Preemptible VMs now up to 33% cheaper blog Interview PHP on Google Cloud Platform docs PHP App Engine Getting Started docs Run PHP on Compute Engine docs Create a Guestbook with Redis and PHP on Container Engine docs Quick Start WordPress for Google App Engine github How to Run Symfony Hello World on App Engine docs github Docker images for running PHP applications on the App Engine Flexible Runtime github Cloud Launcher LAMP Stack launcher Question of the week How do I load balance WebSocket connection with a Google Cloud Load Balancer? Setting Up HTTP(S) Load Balancing docs Setting Up Network Load Balancing docs Setting Up SSL proxy for Google Cloud Load Balancing docs When should I use HTTPS load balancing instead of SSL proxy load balancing? faq

Migrar ou não migrar para o cloud? Acredite: houve uma época em que projetos não nasciam na nuvem! Além do Paulo Silveira, temos Roberto Marin e Rodrigo Turini para contar essas histórias, falar um pouco de problemas e preocupações, e também comentar sobre o escorpião no bolso e quanto custa essa brincadeira no fim do mês. Fichinha da biblioteca: Participantes: Paulo Silveira, hip-host Rodrigo Turini, líder de desenvolvimento na Alura Roberto "é rock garotada" Marin, gerente de engenharia na startup Viva Real Sim, nenhum dos dois convidados tem Twitter.... Alguns links citados: Amazon Elastic Bean Stalk Amazon Cloud Watch - monitoramento na nuvem Google App Engine - um cloud Platform as a Service Heroku - outro paas muito conhecido Conteúdo extra: valer ler posts do blog da caelum sobre as nossas antigas migrações 11 soluções que a Caelum usa em cloud Migrando uma aplicação para o Google App Engine A velha discussão do Iaas vs Paas Produção e conteúdo: Alura Cursos online de Tecnologia - https://www.alura.com.br === Caelum Ensino e Inovação Edição e sonorização: Radiofobia Podcast e Multimídia Você já participa do nosso grupo no Facebook? Conte-nos sua experiência em migrar (ou desmigrar!) do cloud. Não, este site não está no cloud! É hipster.

Join us today for a conversation with Andrew Gerrand and Chris Broadfoot from the Go team. They will discuss with your hosts Francesc Campoy and Mark Mandel why Go is so successful for all the things cloud and how you can use it with Google Cloud Platform. About Andrew Andrew has worked on Go at Google since almost the beginning, and has written tons of blog posts and talks on Go. He spends most of his time making Go easier to use. About Chris Chris joined the Go and Cloud teams last year to improve the experience of writing Go applications for Google Cloud Platform. Before that, he worked at Google on the Maps APIs for around five years. Cool thing of the week EVE Fanfest 2016 - Kubernetes and Google Cloud video Interviews The Go programming language web Go on Google App Engine docs Google Santa Tracker web Tweak The Turkey with a Go powered Doodle doodle gofmt command docs goimports command docs Rails Conf 2012 Keynote: Simplicity Matters by Rich Hickey YouTube Bookshelf tutorial for Go on App Engine tutorial The Go Tour Go Samples repo Question of the week Google Cloud Dataflow docs Google BigQuery docs MapReduce wikipedia Where can you find us next? We'll both be speaking at Google I/O next week! Mark will then be at Change the Game SF Francesc will be riding the AIDS/Lifecycle and if you want you can donate. The Go gopher, by Renee French

In the twentieth episode of this podcast, your hosts Francesc and Mark interview Justin Beckwith, a Product Manager at Google Cloud Platform, about how Node.js and the cloud work together. About Justin Justin is a Product Manager, web developer, and geek dad working on the developer experience for Google App Engine. He writes code, speaks at events, and rocks out on the ukulele. Before joining Google, he filled various developer and architect roles with startups, healthcare companies, and universities. He blogs at jbeckwith.com and twitters as @justinbeckwith. Cool thing of the week Google Cloud Datastore simplifies pricing, cuts cost dramatically for most use-cases blog post Google Cloud Datastore gets faster cross-platform API blog post Interview Node.js on Google Cloud docs Node.js on Google App Engine goes beta blog post The Node.js Docker image used by Google App Engine Managed VMs repo Google Cloud Client Library for Node.js repo and npm Experimental Node.js support for Google Cloud Trace repo Cloud Debug support for Node.js applications repo Building Node.js applications on Google Cloud Platform video Google's officially supported Node.js client library for accessing Google APIs repo Run Parse-server on Google Cloud Platform docs NodeSource Partners with Google to Offer N|Solid as Enterprise Node.js Platform on Google Cloud Platform blog post Google Cloud Platform joins the Node.js foundation blog post Question of the week Michael McKenzie asks about Bigtable and how to get started. Research Paper on Bigtable pdf Bigtable samples on github Bigtable Quickstart on github cbt tool to interact with Cloud Bigtable godoc

In the thirteenth episode of this podcast, your hosts Francesc and Mark interview Sara Robinson and Vikrum Nijjar. Sara is now a Developer Advocate for Google Cloud Platform but was part of Firebase until recently, and Vikrum - Firebase employee #1 - works as a Site Reliance Engineer (SRE) for Firebase. Together they discuss the origins, features, and future of Firebase. About Sara Sara is a Developer Advocate on Google's Cloud Platform team, where she helps with developer relations through online content, outreach and events. She has a bachelor's degree in Business and International Studies from Brandeis University. When she's not programming, she can be found running, listening to country music, or finding the best ice cream in SF. Follow Sara on Twitter @SRobTweets. About Vikrum Vikrum is a Bay Area native and SWE-SRE on the Firebase team. He started out with startups in the 90s with Speedera and has been with Firebase as employee #1 as they were going through YCombinator during the summer of 2011. He has a degree in CS from UC San Diego and enjoys a deep conspiracy with his boba tea. Follow Vikrum on Twitter at @Vikrum5000. Cool thing of the week CP100A: Google Cloud Platform Foundations courses. Interview Firebase. Firebase Documentation. Warby Parker Pneumatic Tubes blog. Roll 20 and their case study. Netty.io. Firebase plugin for Unity blog and github. Firebase pricing doc. Parse moving on blog. Use Firebase and Google App Engine in an Android App tutorial. Firebase - Almost 1.5 years with Google blog. Question of the week Google Cloud Console on Android and iOS.

This month we spoke with Sid Doshi of Homejoy to talk about how they built "Uber for cleaning services." Homejoy is now available in more than 30 cities throughout the US and Canada - covering over 100m households. We dove into their MVP and how they scaled it, their move from Google App Engine to AWS, and what's next for their popular home cleaning service. Listen in to hear how Homejoy created their global home services platform!

En esta ocasión, Santiago Valderrama nos hace una introducción a los diferentes servicios que Google ofrece en la nube orientados al desarrollo de aplicaciones, y mas en concreto, Google App Engine como Platform-as-a-Service. Analizaremos los diferentes servicios que ofrece, sus ventajas e inconvenientes, y los sistemas de almacenamiento disponibles, ya sean relacionales o no relacionales [...]

Tobias Kaatz talks to former Kixeye CTO Randy Shoup about company culture in the software industry in this sequel to the show on hiring in the software industry (Episode 208). Prior to Kixeye, Randy worked as director of engineering at Google for the Google App Engine and as chief engineer and distinguished architect at eBay. […]

On this episode we chat with attorney, gamer and maker Tony Sarkees. He teaches us that copyright laws were actually created to “propagate ideas, encourage creation of new works, inform the public and build a common culture.” Tony is modding his old school Game Boy. Dissected, Painted and let’s get biverted. We talk about the now defunct PMOG/Nethernet and Tony suggests reading Justin’s essay on building online social games. We all bond over the gorgeous gem known as Saugatuck, MI. Pumping Station: One is the Chicago area hackerspace of choice for Tony when he’s making and creating. Tony taught himself CSS to publish a zine online where people can share how gaming and games have affected their lives. Be sure to check out the excellent design and the memoirs featured on electro bureau. Parallax scrolling was the bread & butter of the startup, Scrollkit who got into some legal trouble for showing people how to use their service to create pages like Snow Fall. Chris was looking at about.me and flavors.me in order to build a personal landing page. Tony convinces him otherwise. Our guest recommends hosting a website using Google App Engine instead of purchasing hosting. Let me Duck Duck Go That for you. Tony gives us a lecture on copyright because “it touches every single one of us.” Pay attention! There’s a quiz later. Copyright is actually much more fascinating than you might think. The Statute of Anne was the first copyright law. Moral rights allow creators to control the association of their work in the EU or Canada. That is, “”you can’t use my song in your commercial for your diabolical political party commercials.”“ Fan fiction, fan sites and fan art are all actually copyright infringement. Tony talks Android: Netrunner, a Living Card Game by Fantasy Flight Games. Unfortunately, one of the best communities for the game was shut down. Disney has gone from sue happy to relaxed when it comes to copyright infringement. Our guest doesn’t purchase items from Sony because of their rootkit scandal. All of us are confused by the #gamergate situation. Ridiculous Fishing is a game for iOS suggested by our guest. Paul & Tony really like Threes! which has been cloned many, many times because you can’t copyright game rules and mechanics. You can find Tony on twitter, his site, the electro bureau or grab some of the things he makes at his shop. Support Montreal Sauce on Patreon

With this episode, Software Engineering Radio begins a series of interviews on social/nontechnical aspects of working as a software engineer as Tobias Kaatz talks to Randy Shoup, former CTO at KIXEYE, about hiring in the software industry. Prior to KIXEYE, Randy worked as director of engineering at Google for the Google App Engine and as […]

Didier, Guillaume, Nicolas et Aurérien nous donnent leur retour sur Google I/O. On discute ambiance, material design, wearable, Android, Google App Engine, Dart, Google Compute Engine, Cloud et Glass. Enregistré le 28 juillet 2014 Téléchargement de l’épisode LesCastCodeurs-Episode–107.mp3 Interview Grand merci à Sfeir non seulement de venir parler de Google I/O mais aussi de sponsoriser l’épisode. Tout ça parce ce qu’il aiment bien ce que l’on fait. Nous aussi on les aime bien :) Ta vie, ton oeuvre Didier Girard Google Developer Experts Google Developer Groups Guillaume Giroux Dartlang [FR] Nicolas François (G+, Twitter) Aurélien Pelletier (blog) Ambiance Google I/O Les cadeaux de Google I/O Google Cardboard Stéréoscopie Material design Material design Google Polymer Showcase de material design avec polymer Web Components La spec Web Components Polyfill x-tags AngularJS Code Labs Wearable Android Wearable Google watch K 2000 Sneakers Google Now Android Google Play Services Dalvik et ART Android L Android TV Chromecast Dart Dart dans le Cloud Microsoft Project Volta Chrome Dev Editor Google côté serveur Google Cloud Endpoints Google Cloud Dataflow Google Dataflow vs Hadoop Google Cloud Pub/Sub iBeacon Big Data et Cloud via sur l’infrastructure Google par Didier Girard Google Compute Engine Docker Kubernetes Project Atomic Core OS Services Gmail API Google Apps Script Pris pour Google Apps Entreprise Divers Plus de femmes à Google I/O Google Glass Google+ Stories Emmanuel et les Google Glass Pour aller plus loin Vidéos de Google I/O Article sur Google I/O dans Les Echos Nous contacter Contactez-nous via twitter http://twitter.com/lescastcodeurs sur le groupe Google http://groups.google.com/group/lescastcodeurs ou sur le site web http://lescastcodeurs.com/ Flattr-ez nous (dons) sur http://lescastcodeurs.com/ En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com

Emmanuel, Arnaud, Guillaume et Vincent discutent du programme et du call for paper de Devoxx France. Ils discutent aussi du comportement à adopter face aux failles de sécurité et le reste des nouvelles du monde Java. Enregistré le 3 mars 2014 Téléchargement de l’épisode LesCastCodeurs-Episode–97.mp3 News Conferences Le programme Devoxx France Les têtes à claques - Le willy Waller 2006 Retour de Fosdem Systèmes d’exploitation Apple victime d’une grosse faille de sécurité Goto considered harmful Dashlane Langages La nouvelle représentation de String en Java Frameworks Drools and jBPM 6 Netty 4.0.17 Plateformes Solr 4.7 ElasticSearch 1.0 Google App Engine 1.9 what a surprise. our @googlecloud #appengine started failing as yet another silent runtime upgrade to 1.9.0 had happen. – @musketyr WildFly 8 est sorti avec la certification Java EE 7 Bases de données fun fact: if you scale a cpu cycle (0.12ns on my laptop) to one second an in memory hash lookup takes 30days, a redis lookup 1 year –@pyr Hibernate OGM 4.1 Beta1 Spring Data L’accès aux bases de données relationelles en Scala Tooling Github lance son projet d’éditeur de texte, Atom Vim Le livre Apache Maven est open source et en asciidoc (enfin il y a encore du boulot :-) ) Apache Maven 3.2.1 est sorti Faire ses schemas en asciidoc How Twitter Monitors Millions of Time series Git et la signature de ses commits Les bonnes pratiques de messages de commit d’OpenStack Arquillian Undertow en alpha Griffon 1.5 Blog post sur CRaSH en pratique Front-end Recommendations de style AngularJS par Google Cloud Pivotal transforme CloudFoundry en une fondation when [a project is taken over] by [ASF], it leads to some strange behaviors in terms of hiring committers Méthodologies Feedback à 30% Utiliser @Deprecated correctement Codehaus laisse son DNS expirer, oops. Quelques conseils pour un code sécurisé People David Gageot est Java Champion Docker VirtualBox Salaires dans la silicon valley Outil de l’épisode ClasspathSuite Conférences Devoxx France BreizhCamp Nous contacter Contactez-nous via twitter http://twitter.com/lescastcodeurs sur le groupe Google http://groups.google.com/group/lescastcodeurs ou sur le site web http://lescastcodeurs.com/ Flattr-ez nous (dons) sur http://lescastcodeurs.com/ En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com

Enregistré le 12 juillet 2013 Téléchargement de l’épisode LesCastCodeurs-Episode–83.mp3 News Langages et JVM Scala et la bourde de Rod Johnson http://code.technically.us/post/54293186930/scala-in-2007-2013 L’alignement des structures en mémoire http://www.infoq.com/news/2013/06/Native-Performance Article sur le GC G1 http://www.insightfullogic.com/blog/2013/jun/24/garbage-collection-java-4/ Intégration avec IntelliJ IDEA d’une VM qui permet du full HotSwap en développment http://blogs.jetbrains.com/idea/2013/07/get-true-hot-swap-in-java-with-dcevm-and-intellij-idea/ DCEVM http://ssw.jku.at/dcevm/ Java 8 feature complète http://j.mp/11OqItQ Article expliquant que les utilisateurs de Groovy seront prêts à passer facilement à Java 8 http://www.infoq.com/articles/groovy-to-Java-8 Oracle moins soucieux de la backward compatibilité ? Shay Banon qui note qu’une update change la sérialisation de InetAddress https://twitter.com/kimchy/status/354881694282690560 Projet Groovy affecté par la suppression d’une méthode dans un package sun.* mais aucun workaround proposé http://www.infoq.com/news/2013/07/Oracle-Removes-getCallerClass et http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8014925 Vulnérabilité des JavaDocs http://www.kb.cert.org/vuls/id/225657 Un fix releasé dans la foulée par Cédric Champeau pour Gradle avec un plugin https://github.com/melix/gradle-javadoc-hotfix-plugin Un fix releasé dans la foulée par Olivier Lamy pour Maven avec la MAJ du plugin javadoc (2.9.1) http://maven.apache.org/plugins/maven-javadoc-plugin Web GWT.create, une conférence 100% sur GWT http://gwtcreate.com Encodage d’URL, vous avez tord http://blog.lunatech.com/2009/02/03/what-every-web-developer-must-know-about-url-encoding Retour d’expérience sur le tout JavaScript http://fr.slideshare.net/nzakas/enough-withthejavascriptalready Mobile et Bureau Les jeux iOS vs Androïd http://games.greggman.com/game/android-vs-ios-game-myths/ Liens sur Java Desktop http://jonathangiles.net/blog/?p=1483 Java EE et serveurs d’application Les presentations des différentes specs http://www.youtube.com/playlist?list=PL74xrT3oGQfCCLFJ2HCTR_iN5hV4penDz JSR 107 en public draft review Pivotal tcserver vs Apache Tomcat http://blog.gopivotal.com/products/part-one-comparing-tomcat-and-pivotal-tc-server Introduction à Inject et Default http://java.dzone.com/articles/cdi-default-and-inject La roadmap de Play 2.x https://docs.google.com/document/d/11sVi1-REAIDFVHvwBrfRt1uXkBzROHQYgmcZNGJtDnA/pub WildFly 8 alpha 2 est sorti http://jboss-as7-development.1055759.n5.nabble.com/wildfly-dev-8-0-0-Alpha2-Released-td5712259.html Feature Flipping For Java http://ff4j.org/ NoSQL et Big Data et cloud Les mythes de Cassandra http://www.infoq.com/articles/cassandra-mythology HortonWprks reçoit 50 M http://www.crunchbase.com/company/hortonworks Le tck de Google App Engine et CapeDwarf http://www.infoworld.com/d/cloud-computing/google-and-red-hat-collaborate-app-engine-in-private-clouds-221214 Outils GitHub introduit la capacité de releaser une librairie https://github.com/blog/1547-release-your-software limité à 100 MB de stockage pas de statistiques de téléchargement Bintray https://bintray.com Eclipse Kepler est sorti http://eclipse.org/kepler/ m2eclipse http://www.eclipse.org/m2e/ Arquillian pour Spring et Guice http://bit.ly/19U3f2t http://bit.ly/16Nhr9J Packer, un créateur de VMs concurrent de Veewee créé par l’auteur de Vagrant http://www.packer.io/ Bon tuto Git en Francais : http://www.miximum.fr/tutos/1546-enfin-comprendre-git Reutiliser des plugins Maven pour construire son propre plugin Maven : https://github.com/TimMoore/mojo-executor Divers Oracle relicence BerkleyDB de Sleepycat vers AGPL 3.0 http://article.gmane.org/gmane.linux.debian.devel.legal/35034 Douglas Engelbart, L’inventeur de la souris est mort http://www.nytimes.com/2013/07/04/technology/douglas-c-engelbart-inventor-of-the-computer-mouse-dies-at-88.html?ref=obituaries&_r=0 Encrypter ses données dropbox http://goo.gl/EUT1E Se faire son dropbox sécurisé chez soi avec son disque dur externe http://www.kickstarter.com/projects/cloud-guys/plug-the-brain-of-your-devices Sécuriser ses clefs SSH http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html InfoQ en Français http://www.infoq.com/fr Outils de l’épisode Ncdu (disk usage in command line http://dev.yorhel.nl/ncdu Encfs http://www.arg0.net/encfs JUG et Conferences JUG Summer Camp - 20 septembre https://sites.google.com/site/jugsummercamp/ Codeurs en Seine - 17 octobre 2013 - http://www.codeursenseine.com/ Scala IO - 24–25 Octobre 2013 - the Scala and functionnal programming conference in Paris http://scala.io/ Soft Shake 24, 25 octobre à Genève Devoxx Belgique - 11 - 15 Nov - http://www.devoxx.be/#/ Nous contacter Contactez-nous via twitter http://twitter.com/lescastcodeurs sur le groupe Google http://groups.google.com/group/lescastcodeurs ou sur le site web http://lescastcodeurs.com/ Flattr-ez nous (dons) sur http://lescastcodeurs.com/ En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com

Enregistré le 8 mars 2013 Téléchargement de l’épisode LesCastCodeurs-Episode–75.mp3 News Java Nouvelle faille, nouveau patch http://bit.ly/WEHvx9 Guide sur le code sécurisé en Java http://www.oracle.com/technetwork/java/seccodeguide-139067.html Algorithmes non-bloquants en Java http://www.ibm.com/developerworks/java/library/j-jtp04186/index.html Maven 3.0.5 et repos en HTTPS http://goo.gl/RvFN9 Blog sur la stack Scala http://goo.gl/1jw9w Statut sur JDK 8 http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-February/002066.html Java Rockstars http://www.oracle.com/javaone/quick-links/rock-star/javaone-2012-rockstars-1903190.html Java Champions http://java-champions.java.net Java Metaspace http://java.dzone.com/articles/java-8-permgen-metaspace Frameworks et plateformes Jean-François Arcand se lance sur le support d’Atmosphere http://jfarcand.wordpress.com/2013/03/04/can-i-make-a-living-out-of-my-open-source-projects-in-5-months/ Red Hat donne accès aux binaires de JBoss EAP http://www.jboss.org/jbossas/downloads https://community.jboss.org/blogs/mark.little/2013/03/07/eap-binaries-available-for-all-developers Cloud et Big Data IBM rejoint OpenStack http://gigaom.com/2013/03/04/finally-ibm-drops-the-other-openstack-shoe/ Votre premier projet Hadoop http://blog.octo.com/votre-premier-projet-hadoop/ CloudBees offre l’integration continue pour CloudFoundry http://gigaom.com/2013/02/28/cloudbees-offers-cloud-foundry-integration/ Codeenvy lève 9 millions de dollars http://blog.exoplatform.com/2013/02/26/from-exo-cloud-ide-to-codenvy-raising-9-million-dollars-a-brief-history Codenvy: retour de Nicolas DeLoof http://blog.loof.fr/2013/02/codenvy-lide-dans-le-cloud.html Koding https://koding.com Google App Engine, nouveaux packages de support http://googleappengine.blogspot.fr/2013/02/google-cloud-platform-introduces-new.html L’étude geek et cloud de Devoxx France https://www.surveymonkey.com/s/ducloudetdesgeeks Heroku et l’algo de routage http://rapgenius.com/James-somers-herokus-ugly-secret-lyrics Mobile Facebook et son hack Android http://jaxenter.com/facebook-s-completely-insane-dalvik-hack-46376.html Autres Twitter offre un nouveau client Java pour son flux http://engineering.twitter.com/2013/02/drinking-from-streaming-api.html Travailler à la maison: pas chez Yahoo http://www.businessinsider.com/ex-yahoos-confess-marissa-mayer-is-right-to-ban-working-from-home-2013-2?0=sai L’association fier d’être développeur http://goo.gl/FXrJu Outils de l’épisode Cal10n http://cal10n.qos.ch JBoss Logging git-crypt http://www.agwa.name/projects/git-crypt/ Les mains dans le cambouis JUG et Conferences Devoxx France 27–29 mars Pilly Emerging Tech 2–3 avril DevopsDays Paris 18–19 avril Mix-IT 25 et 26 avril CloudConf Paris le 7–8 juin Red Hat Summit 11–14 juin Nous contacter Contactez-nous via twitter http://twitter.com/lescastcodeurs sur le groupe Google http://groups.google.com/group/lescastcodeurs ou sur le site web http://lescastcodeurs.com/ Flattr-ez nous (dons) sur http://lescastcodeurs.com/ En savoir plus sur le sponsoring? sponsors@lescastcodeurs.com

Enregistré le 25 février 2013 Téléchargement de l’épisode LesCastCodeurs-Episode–74.mp3 Sponsoring Intéressé pour sponsoriser les cast codeurs et voir ce que cela peut vous apporter ? Contactez nous à sponsors@lescastcodeurs.com Interview Introduction Eric Bottard @ebottard VMware http://www.vmware.com Définitions du PaaS PaaS http://en.wikipedia.org/wiki/Platform_as_a_service CloudFoundry http://cloudfoundry.com OpenShift https://openshift.redhat.com/app/ CloudBees http://www.cloudbees.com Heroku http://www.heroku.com Google App Engine https://cloud.google.com/products/ CloudFoundry CloudFoundry http://cloudfoundry.com AppFog https://www.appfog.com Tier3 http://www.tier3.com Node.js http://nodejs.org Spring Framework http://www.springsource.org/spring-framework Grails http://grails.org MySQL http://www.mysql.com PostgreSQL http://www.postgresql.org MongoDB http://www.mongodb.org Redis http://redis.io RabbitMQ http://www.rabbitmq.com Code Story http://code-story.net Pour le DevOps VMC http://docs.cloudfoundry.com/tools/vmc/installing-vmc.html Plugin Eclipse http://docs.cloudfoundry.com/tools/STS/configuring-STS.html Blog sur les deployments sur CloudFoundry http://blog.springsource.com/2011/09/22/rapid-cloud-foundry-deployments-with-maven/ Subversion http://subversion.tigris.org Git http://git-scm.com Etude Zero Turnaround http://zeroturnaround.com/labs/devprod-report-revisited-version-control-systems-in-2013/ SHA–1 http://en.wikipedia.org/wiki/SHA-1 BCrypt http://en.wikipedia.org/wiki/Bcrypt jBCrypt https://github.com/jeremyh/jBCrypt Jenkins http://jenkins-ci.org New Relic http://newrelic.com Business model OVH http://www.ovh.com/fr/vps/ Le moteur CloudFoundry Bosh https://github.com/cloudfoundry/bosh Micro CloudFoundry https://micro.cloudfoundry.com La communauté CloudFoundry.org http://cloudfoundry.org core.cloudfoundry.com http://core.cloudfoundry.org Le futur La roadmap Le blog CloudFoundry http://blog.cloudfoundry.com Nous contacter Contactez-nous via twitter http://twitter.com/lescastcodeurs sur le groupe Google http://groups.google.com/group/lescastcodeurs ou sur le site web http://lescastcodeurs.com/ Flattr-ez nous (dons) sur http://lescastcodeurs.com/