The InfoQ Podcast

Ludwig is a code-free deep learning toolbox originally created and open sourced by UberAI. Today, on the podcast the creator of Ludwig Piero Molino and Wes Reisz discuss the project. The two talk about how the project works, its strengths, it’s roadmap, and how it’s being used by companies inside (and outside) of Uber. They wrap by discussing path ahead for Ludwig and how you can get involved with the project. Why listen to this podcast: • Uber AI is the research and platform team for everything AI at the company with the exception of self-driving cars. Self-driving cars are left to Uber ATG. • Ludwig allows you to specify a Tensorflow model in a declarative format that focuses on your inputs and outputs. Ludwig then builds a model that can deal with those types of inputs and outputs without a developer explicitly specifying how that is done. • Because of Ludwig’s datatype abstraction for inputs and outputs, there is a huge range of applications that can be created. For example, an input could be text and output could be a category. In this case, Ludwig will create a text classifier. An image and text input (such as a question: “Is there a dog in this image”) would output a question answering system. There are many combinations that are possible with Ludwig. • Uber is using Ludwig for text classification for customer support. • Datatypes can be extended easily with Ludwig for custom use cases. • Ludwig would love to have people contribute to the project. There are simple feature requests that are just not prioritized with the current contributor workload. It’s a great place to get involved with machine learning and gain experience with the project. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2JGA5wC You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2JGA5wC From time to time InfoQ publishes trend reports on the key topics we’re following, including a recent one on DevOps and Cloud. So if you are curious about how we see that state of adoption for topics like Kubernetes, Chaos Engineering, or AIOps point a browser to http://infoq.link/devops-trends-2019.

Ben Sigelman is the CEO of Lightstep and the author of the Dapper paper that spawned distributed tracing discussions in the software industry. On the podcast today, Ben discusses with Wes observability, and his thoughts on logging, metrics, and tracing. The two discuss detection and refinement as the real problem when it comes to diagnosing and troubleshooting incidents with data. The podcast is full of useful tips on building and implementing an effective observability strategy. Why listen to this podcast: - If you’re getting woke up for an alert, it should actually be an emergency. When that happens, things to think about include: when did this happen, how quickly is it changing, how did it change, and what things in my entire system are correlated with that change. - A reality that seems to be happening in our industry is that we’re coupling the move to microservices with a move to allowing teams to fully self-determine technology stacks. This is dangerous because we’re not at the stage where all languages/tools/frameworks are equivalent. - While a service mesh offers a great potential for integrations at layer 7 many people have unrealistic expectations on how much observability will be enabled by a service mesh. The service mesh does a great job of showing you the communication between the services, but often the details get lost in the work that’s being done inside the service. Service owners need to still do much more work to instrument applications. - Too many people focus on the 3 Pillars of Observability. While logs, metrics, and tracing are important, observability strategy ought to be more focused on the core workflows and needs around detection and refinement. - Logging about individual transactions is better done with tracing. It’s unaffordable at scale to do otherwise. - Just like logging, metrics about individual transactions are less valuable. Application level metrics such as how long a queue is are metrics that are truly useful. - The problem with metrics are the only tools you have in a metrics system to explain the variations that you’re seeing is grouping by tags. The tags you want to group by have high cardinality, so you can’t group them. You end up in a catch 22. - Tracing is about taking traces and doing something useful with them. If you look at hundreds or thousands of tracing, you can answer really important questions about what’s changing in terms of workloads and dependencies about a system with evidence. - When it comes to serverless, tracing is more important than ever because everything is so ephemeral. Node is one of the most popular serverless languages/frameworks and, unfortunately, also one of the hardest of all to trace. - The most important thing is to make sure that you choose something portable for the actual instrumentation piece of a distributed tracing system. You don’t want to go back and rip out the instrumentation because you want to switch vendors. This is becoming conventional wisdom. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2PPIdeE You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2PPIdeE

- Web Assembly (wasm) is a set of instructions or a low-level byte code that is a target for higher level languages. It was added to the browser because it was a portion of the web platform that many felt was just missing. - Wasm is still a young technology. It performs really well for computationally intensive applications and also offers performance consistency (because it lacks a garbage collector). - Bootstrapping an application using the Rust toolchain looks like: pull down a template, export a function using an attribute (defines that you want to access this function from JavaScript), and run a tool called wasm-pack (compiles it into Web Assembly and then runs a tool called wasm-bindgen that generated Rust types for Wasm). Then you can talk to that binary as if it was written in JavaScript in your code. - Cloudflare workers allow JavaScript that you might have written for a server to be written and distributed at the application edge (or close to the end user). It uses a similar model as serverless architecture platforms. - Interesting use cases such as A/B testing, DDoS prevention, server-side rendering, or traffic shaping can be done at the edge. - Wasm is an approach to bringing full application experiences to the edge. - Wasi (Web Assembly System Interface) is a standardized interface for running Web Assembly for places that are outside of the web. Fastly recently released a pure Web Assembly runtime for their edge that is built on top of Wasi called Lucet (allows access to lower level things at the edge like sockets and UDP). - Zoom has a web client written in Web Assembly. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2Dw3jcH You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2Dw3jcH

Bryan Cantrill is the CTO of Joyent and well known for the development of DTrace at Sun Microsystems. Today on the podcast, Bryan discusses with Wes Reisz a bit about the origins of DTrace and then spends the rest of the time discussing why he feels Rust is the “biggest development in systems development in his career.” The podcast wraps with a bit about why Bryan feels we should be rewriting parts of the operating system in Rust. Why listen to the podcast: • DTrace came down to a desire to use Dynamic Program Text Modification to instrument running systems (much like debuggers do) and has its origins to when Bryan was an undergraduate. • When a programming language delivers something to you, it takes it from you in the runtime. The classic example of this is garbage collection. The programming language gives you the ability to use memory dynamically without thinking of how the memory is stored in the system, but then it’s going to exact a runtime cost. • One of the issues with C is that it just doesn’t compose well. You can’t just necessarily pull a library off the Internet and use it well. Everyone’s C is laden with some many idiosyncrasies on how it’s used and the contract on how memory is used. • Ownership is statically tracking who owns the structure. It’s ownership and the absence of GC that allows you to address the composability issues found in C. • It’s really easy in C to have integer overflow which leads to memory safety issues that can be exploited by an attacker. Rust makes this pretty much impossible because it’s very good at how it determines how you use signed vs unsigned types. • You don’t want people solving the same problems over and over again. You want composability. You want abstractions. What you don’t want is where you’ve removed so much developer friction that you develop code that is riddled with problems. For example, it slows a developer down to force them to run a linter, but it results in better artifacts. Rust effective builds a lot of that linter checking into the memory management/type checking system. • While there’s some learning curve to Rust. It’s not that bad if you realize there are several core concepts you need to understand to understand Rust. Rust is one of those languages that you really need to learn in a structured way. Sit down with a book and learn it. • Rust struggles when you have objects that are multiply owned (such as a Doubly Linked List). It’s because it doesn’t know who owns what. While Rust supports unsafe operations, you should resist the temptation to develop with a lot of unsafe operations if you want the benefits of what Rust offers developers. • Firmware is a great spot for growing Rust development in a process of replacing bits of what we think of as the operating system. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2uZ5QHZ You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2uZ5QHZ

Duncan Macgregor speaks with Wes Reisz about the work being done on the experimental Graal Compiler. He talks about the use cases and where the new JIT compiler excels really well (compared to C2). In addition, Duncan talks about the relationship of Graal to Truffle. The two then discuss a language Duncan works on at OracleLabs (TruffleRuby) that is being implemented on the stack. Finally, the podcast wraps with a discussion of Project Loom and its relationship to TruffleRuby and Graal. Why listen to this podcast: - Graal is a replacement for the JVM’s C2 JIT compiler. It was tracked with JEP 295 (Ahead-of-Time Compilation) and included in Java 9. As of Java 10, Graal is experimental for the Linux x64 platform. - Graal is written in Java and excels at implementing code that takes a functional approach to solving problems (such as Scala). It can also offer improvements / optimizations for other languages (including other non-traditional JVM languages such as C and Ruby). - Truffle is a language implementation framework used my Graal. The idea is rather than having to write a compiler for your language, you can write an interpreter. This gives you the ability to write specializations at a higher level of abstraction that yields performance and better understanding. - Truffle’s architecture and design allows things like allowing unrelated languages to do interop, garbage collection, and types. - TruffleRuby and JRuby started off with a lot of shared code. They’ve branched and JRuby today focuses on integration with other Java classes. It compiles to bytecode and then relies on the C2 JIT to run on the JVM. TruffleRuby doesn’t try to compile to Java classes and only uses the Truffle framework to compile the things it needs. TruffleRuby is able to use most of native Ruby. - Project Loom is a project that aims to add one shot delimited continuations to the JVM. It leverages fibers (a much lighter concurrency primitive than threads) and can literally run millions of them.

Today on The InfoQ Podcast, Wes talks with Rod Johnson. Rod is famously responsible for the creation of the Spring Framework. The two talk about the early years of the framework and provides some of the history of its creation. After discussing Spring, Wes and Rod discuss languages he’s been involved with since Java (these include Scala and TypeScript). He talks a bit about what he liked (and didn’t like) about each. Finally, the two wrap by discussing Atomist and how they’re trying to change the idea of software delivery from a statically defined pipeline (located in individual repositories) to an event hub that drives a series of actions for software delivery. He describes this as creating an API for your software. Why listen to this podcast: - The initial origins of the Spring Framework really came about through a process of trying to write a really great book about J2EE in 2002. It was through that process that Rod Johnson found he felt there was a better way and ultimately lead to the creation of the Spring Framework. - What started as examples and references, became the Spring Framework. By 2005 there were about 2 million downloads of the Spring Framework. After leaving VMWare in 2013, Rod spent several years working with Scala. One of the elegant features that really attracted Rod to Scala was how everything is an expression. One of the things he didn’t like was an affinity to overly complex approaches to problem solving. - Today at Atomist, Rod does a lot of work in Node. He really enjoys the robust extra layer of typing over a dynamic language and the ability to escape to JavaScript if needed (similar to escaping types with reflection in Java found in the internals of the Spring Framework). - Atomist, the company he founded after leaving VMWare, is rethinking CI/CD from a static pipeline defined in every repository to an event-driven system that defines how to respond to specific events (such as a push from Git). For example, all pushes with Spring Boot can be configured to be scanned with SonarQube or because a push has kubespec it might get deployed to a K8 cluster. He describes this as creating an API for your software. - One of the reasons Atomist integrates so tightly with Slack (and other similar messaging platforms) is because it allows developers to shape their own relevant messages. By joining (or leaving channels), people are able to subscribe to only the information they actually want. Meeting developers inside Slack is an important interface for Atomist. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2FxK3xf You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2FxK3xf

Today on The InfoQ Podcast, Wes talks with Katharine Jarmul about privacy and fairness in machine learning algorithms. Katharine discusses what’s meant by Ethical Machine Learning and some things to consider when working towards achieving fairness. Katharine is the Co-Founder at KIProtect a machine learning security and privacy firm based in Germany and is one of the three keynotes at QCon.ai. Why listen to this podcast: - Ethical machine learning is about practices and strategies for creating more ethical machine learning models. There are many highly publicized/documented examples of machine learning gone awry that show the importance of the need to address ethical machine learning. - Some of the first steps to prevent bias in machine learning is awareness. You should take time to identify your team goals and establish fairness criteria that should be revisited over time. This fairness criteria then can be used to establish the minimum fairness criteria allowed in production. - Laws like GDPR in the EU and HIPAA in the US provide privacy and security to users and have legal implications if not followed. - Adversarial examples (like the DolphinAttack that used subsonic sounds to activate voice assistants) can be used to fool a machine learning model into hearing or seeing something that’s not there. More and more machine learning models are becoming an attack vector for bad actors. - Machine learning is always an iterative process. - Zero-Knowledge Computing (or Federated Learning) is an example of machine learning at the edge and is designed to respect the privacy of an individual’s information. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2TD3nSd You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2TD3nSd

Today on The InfoQ Podcast, Wes Reisz speaks with Grady Booch. Grady is well known as the co-creator of UML, an original member of the design patterns movement, and now work he’s doing around Artificial Intelligence. On the podcast today, the two discuss what today’s reality is for AI. Grady answers questions like what does an AI mean to the practice of writing software and around how he seems it impact delivering software. In addition, Grady talks about AI surges (and winters) of over the years, the importance of ethics in software, and host of other related questions. Why listen to this podcast: - There have been prior ages of AI that has lead to immediate winters of where reality set in. It stands to reason, there will be a version of an AI winter that follows today’s excitement around deep learning. - AIs are beginning to look at the code for testing edge cases in software and do things such as looking over your shoulder and identifying patterns in the code that you write. - AIs will remove tedium for software developers; however, software developer is (and will remain) a labor-intensive activity for decades to come.nAI is another bag of tools in a larger systems activity. - Much of the AI developers are young white men from the United States. That has a number of inherent biases in this fact. There are several organizations that are focused on combating some of these biases and bringing ethical learning into the field. This is important for us to be aware of and encourage. - The traditional techniques of systems engineering we know for building non-AI systems will still apply. AI’s are pieces of larger systems. That might be really interesting parts, but it’s just a part of a larger system that requires a lot of non-AI engineering use cases. - Early machine learning systems were mostly learn and forget systems. You teach them, you deploy them, and you walk away. Today, we do continuous learning and we need to integrate these new models into the delivery pipeline. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2SjJOsq You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2SjJOsq

Today on The InfoQ Podcast, Wes talks with Joe Beda. Joe is one of the co-creators of Kubernetes. What started in the fall of 2013 with Craig McLuckie, Joe Beda, and Brendan Burns working on cloud infrastructure has become the default orchestrator for cloud native architectures. Today on the show, the two discuss the recent purchase of Heptio by VMWare, the Kubernetes Privilege Escalation Flaw (and the response to it), Kubernetes Enhancement Proposals, the CNCF/organization of Kubernetes, and some of the future hopes for the platform. Why listen to this podcast: - Heptio, the company Joe and Craig McLuckie co-founded, viewed themselves as not a Kubernetes company, but more of a cloud native company. Joining VMWare allowed the company to continue a mission of helping people decouple “moving to cloud/taking advantage of cloud” patterns (regardless of where you’re running). - Re:Invent 2017 when EKS was announced was a watershed moment for Kubernetes. It marked a time where enough customers were asking for Kubernetes that the major cloud providers started to offer first-class support. - Kubernetes 1.13 included a patch for the Kubernetes Privilege Escalation Flaw Patch. While the flaw was a bad thing, it demonstrated product maturity in the way the community-based security response. - Kubernetes has an idea of committees, sigs, and working groups. Security is one of the committees. There were a small group of people who coordinated the security response. From there, trusted sets of vendors validated and test patches. Most of the response is based on how many other open source projects handle security response. - Over the last couple of releases, Kubernetes has introduced a Sig Architecture special interest group. It’s an overarching review for changes that sweep across Kubernetes. As part of Sig Architecture, the Kubernetes community has introduced Kubernetes Enhancement Proposal process (or KEPs). It’s a way for people to propose architectural changes to Kubernetes. - The goal of the CNCF is to curate and provide support to a set of projects (of which Kubernetes is one). The TOC (Technical Oversight Committee) decides which projects are going to be part of the CNCF and how those projects are supported. - Kubernetes was always viewed by the creators as something to be build on. It was never really viewed as the end goal. You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq

Today on the InfoQ Podcast, Wes speaks with ThirdLove’s Megan Cartwright. Megan is the Director of Data Science for the personalized bra company. In the podcast, Megan first discusses why their customers need a more personal experience and how their using technology to help. She focuses quite a bit of time in the podcast discussing how the team got to an early MVP and then how they did the same for getting to an early machine learning MVP for product recommendations. In this later part, she discusses decisions they made on what data to use, how to get the solution into production quickly, how to update/train new models, and where they needed help. It’s a real early stage startup story of a lean team leveraging machine learning to get to a practical recommendations solution in a very short timeframe. Why listen to this podcast: - The experience for women selecting bras is poor experience characterized by awkward fitting experiences and an often uncomfortable product that may not even fit correctly. ThirdLove is a company built to serve this market. - ThirdLove took a lean approach to develop their architecture. It’s built with the Parse backend. The leveraged Shopify to build the site. The company’s first recommender system used a rules engine embedded into the front end. After that, they moved to a machine learning MVP with a Python recommender service that used a Random Forest algorithm in SciKit-Learn. - Despite having the data for 10 million surveys, the first algorithms only need about 100K records to be trained. The takeaway is you don’t have to have huge amounts of data to get started with machine learning. - To initially deploy their ML solution, ThirdLove first shadowed all traffic through the algorithm and then compared it to what was being output by the rules engine. Using this along with information on the full customer order lifecycle, they validated the ML solution worked correctly and outperformed the rules engine. - ThirdLove’s machine learning story shows that you move towards a machine learning solution quickly by leveraging your own network and using tools that may already familiar to your team. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2G9RnQn You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2G9RnQn

Lynn Langit is a consulting cloud architect who holds recognitions from all three major cloud vendors on her contributions to their respective communities. On today’s podcast, Wes talks with Lynn about a concept she calls 25% time and a project it led her to become involved within genomic research. 25% time is her own method of learning while collaborating with someone else for a greater good. A recent project leads her to become involved with the Commonwealth Scientific and Industrial Research Organisation (CSIRO) in Australia. Through cloud adoption and some lean startup practices, they were able to drop the run time for a machine learning algorithm against a genomic dataset from 500 hours to 10 minutes. Why listen to this podcast: - 25% time is a way to learn, study, or collaborate with someone else for a greater good. It’s unbilled time in the service of offers. Using the idea of 25% time along with some personal events that occurred in her life, Lynn became involved with genomic researchers in Australia. - Price of genomic sequencing has dropped. The price drop has enabled researchers to create huge repositories of genomic data; however, it was mostly on-prem. The idea of building data pipelines was pretty new in the genome community. Additionally, the genome itself is 3 billion data points. A variant of as little at 10-15 variants can be statistically significant. - The challenge was to leverage cloud resources. To gain a quick win and buy-in for Commonwealth Scientific and Industrial Research Organisation (or CSIRO an independent Australian federal government agency) for cloud adoption, a first step was to capture interest in the idea. So the team stored their reference data in the cloud and enabled access via a Jupyter Notebook. - They demonstrated a use case against the genomic data set leveraging a synthetic phenotype (or a fake disease) called hipsterdom. The solution became a basis for global discussion that got more people involved in the community. - By leveraging cloud resources, the CSIRO was able to get a run their dataset that took 500 hours against an on-prem Spark cluster to 10 minutes. - Learning new programming language has unseen benefits. For example, Ballerina (a language written as an integration language between APIs) interested Lynn because of its live visual diagrams; however, benefited her with some of the cloud pipelines because of its ability to produce YAML files. You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2T2LZBQ

In this podcast Charles Humble and Wes Reisz talk about autonomous vehicles, GDPR, quantum computing, microservices, AR/VR and more. * Waymo vehicles are now allowed to be on the road in California running fully autonomous; they seem to be a long way ahead in terms of the number of autonomous miles they’ve driven, but there are something like 60 other companies in California approved to test autonomous vehicles. * It seems reasonable to assume that considerably more regulation around privacy will appear over the next few years, as governments and regulators grapple with not only social media but also who owns the data from technology like AR glasses or self-driving cars. * We’ve seen a huge amount of interest in the ethical implications of technology this year, with Uber getting into some regulatory trouble, and Facebook being co-opted by foreign governments for nefarious purposes. As software becomes more and more pervasive in people's lives the ethical impact of what we all do becomes more and more profound. * Researchers from IBM, the University of Waterloo, Canada, and the Technical University of Munich, Germany, have proved theoretically that quantum computers can solve certain problems faster than classical computers. * We’re also seeing a lot of interest around human computer interaction - AR, VR, voice, neural interfaces. We had a presentation at QCon San Francisco from CTRL-labs, who are working on neural interfaces - in this case interpreting nerve signals - and they have working prototypes. Much like touch this could open up computing to another whole group of people.

On this week’s podcast, Wes Reisz talks with Brian Goetz. Brian is the Java Language Architect at Oracle. The two start with a discussion on what the six-month cadence has meant to the teams developing Java. Then move to a review of the features in Java 9 through 12. Finally, the two discuss the longer-term side projects (such as Amber, Loom, and Valhalla) and their role in the larger release process for the JDK. * The JVM’s sixth-month cadence changed the way the JDK is delivered and planned. While it definitely provides more rapid delivery at expected intervals, the release train approach turned out to also improve flexibility and efficiency. * Oracle JDK and OpenJDK are almost identical. Most of the JDK distributions are forks from OpenJDK with different bug fixes and backports applied. So the difference between the distributions now is largely which bug fixes are picked up. * Local Variable inference (which was released as part of Java 10) illustrated the tension on making changes to the language. Many people wanted the change, but many others felt it would enable people to write bad code. Oracle had to balance the two views when making the change. * The number of Java versions allow finer grain decision making on what is appropriate for an application. With the adoption of containers, applications are bundled with an exact JDK version rather than having to use one from a systems level. The different versions give developers more options. * Incubating features are new libraries added to the JDK. They were offered starting with Java 9 as a way for people to test and offer feedback more rapidly. With Java 12, preview features will be released. Preview features are similar but are core platform and language features. * Shenandoah and ZGC are both low latency garbage collectors. They originally came from different sources. While both garbage collectors are similar, each has different performance characteristics under different workloads. The two garbage collectors represent options available to JVM developers. * Most non-trivial JDK features take more than six months to develop. Longer term side projects like Amber, Loom, Valhalla are where these features are developed prior to being released with a version of the JDK. The projects range from language enhancements to concurrency work.

This week on the InfoQ Podcast, Wes Reisz talks to Tanya Reilly (Principal Engineer at Squarespace and previously a staff SRE at Google). Tanya discusses her research into how the fire code evolved in New York and draws on some of the parallels she sees in software. Along the way, she discusses what it means to be an SRE, what effective aspects of the role might look like, and her opinions on what we as an industry should be doing to prevent disasters. This podcast features discussion on paved roads, prevention, testing, firefighting (in software), and reliability questions to ask throughout the software lifecycle. Why listen to this podcast: - Teams increasingly are responsible for the entire software lifecycle. When this happens, they think about the software differently because they know their the ones that will get paged if it fails. This idea is at the core of the “You Build It, You Run It” philosophy in DevOps. - The role of SRE is to define how to do things in a really reliable way. The focus is to make the majority of the operations work go away, and, for the things that can’t go away, it’s as easy as possible. - At the very start of a project (when you’re writing the initial design), you should be thinking about the dependencies for a system and how will those that follow with be able to determine that. A great way to do this is to offer an API that people will want to use and then instrument it. - We can learn a lot from the growth of fire safety regulations as metaphors for software, including: fireproof interior walls, socializing best practices, software inspections, and circuit breakers are all examples. - The work SREs do varies in many places. SREs range from making recommendations on patterns to library creators in other areas. Occasionally, SREs are firefighters of last resort. In these cases, they’re the last resort though. - We use error budgets and SLOs to quantify how many much risk we’re comfortable taking. It’s used to inform how much less (or more risk) we’re willing to take on. - We need to consider software reliability throughout the full cycle of software development. When you build systems. Think about as if there will not be someone on call for it . You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq

On today’s podcast, Wes Reisz talks with Jason Maude of Starling Bank. Starling Bank is a relatively new startup in the United Kingdom working in the banking sector. The two discuss the architecture, technology choices, and design processes used at Starling. In addition, Maude goes into some of the realities of building in the cloud, working with regulators, and proven robustness with practices like chaos testing. Why listen to this podcast: - Starling Bank was created because the government lowered the barrier to entry for banking startups in reaction to previous industry bailouts. - The system is composed of around 19 applications hosted on AWS and running Java and backed by a PostgreSQL database. - These applications are not monolithic but are focused around common functionality (such as a Card or Payment Service). - Java was chosen primarily because of its maturity and long term viability/reliability in the market. - The heart of Starling is every action the system takes happens at least once and at most once. To help with these rules, everything in their system uses as a correlation id (UUID) and are used to make sure these two rules are met. You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq

Martin Fowler chats about the work he’s done over the last couple of years on the rewrite of the original Refactorings book. He discusses how this thought process has changed and how that’s affected the new edition of the book. In addition to discussing Refactors, Martin and Wes discuss his thoughts on evolutionary architecture, team structures, and how the idea of refactors can be applied in larger architecture contexts. Why listen to this podcast: - Refactoring is the idea of trying to identify the sequence of small steps that allows you to make a big change. That core idea hasn’t changed. - Several new refactorings in the book deal with the idea of transforming data structures into other data structures, Combine Functions into Transform for example. - Several of the refactorings were removed or not added to the book in favor of adding them to a web edition of the book. - A lot of the early refactorings are like cleaning the dirt off the glass of a window. You just need them to be able to see where the hell you are and then you can start looking at the broader ones. - Refactorings can be applied broadly to architecture evolution. Two recent posts How to break a Monolith into Microservices, by Zhamak Dehghani, and How to extract a data-rich service from a monolith by Praful Todkar on MartinFowler.com deal with this specifically. - Evolutionary architecture is a broad principle that architecture is constantly changing. While related to Microservices, it’s not Microservices by another name. You could evolve towards or away from Microservices for example. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2QbdHej You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2QbdHej

In June of this year, Consul 1.2 was released. The release expanded Consul’s capability around service segmentation (controlling who and how services connect East and West). On this week’s podcast, Wes and Mitchell discuss Consul in detail. The two discuss Consul’s design decisions around focusing on user space networking, layer 4 routing, Go, Windows’ performance characteristics, the roadmap for eBPF on Linux, and an interesting feature that Consul implements called Network Tomography. The show wraps with Mitchell’s discussion on some of the research that Hashicorp is doing around machine learning and security with Consul. Why listen to this podcast: - Consul is first and foremost a centralized service registry that provides discovery. While it has a key-value store, it is Consul’s least important feature. With the June release (1.2), Consul entered more into the space of a service mesh with the focus on service segmentation (controlling how you connect and who can connect). - Hashicorp attempts to limit the language fragmentation in the Company and has seen a lot of success leveraging Go across their platforms. Therefore, Consul is written in Go. - Because Consul focused on layer 4 first, it is recommended to leverage the recent integration with Envoy for achieving high degrees of observability. - All of the network routing with Consul happens in user space at this point; however, kernel space routing with eBPF is planned for the near term. The focus, at this point, is safely cross-compiling to every platform and addressing the most possible use cases. The focuses isn’t on the high performance use cases (yet). - For any two servers across the globe in different data centers, instantly Consul can give you 99th percentile round-trip time between with uses a feature called Network Tomography. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2S3ZiSx You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2S3ZiSx

On the podcast this week Charles Humble talks to Camille Fournier about running a platform team, how her current role differs from the CTO role she had a Rent the Runway, the skills developers need to acquire as they move from engineering to management positions, tends like Holacracy, and her book "The Manager's Path" Why listen to this podcast: - When looking for platform engineers Camille looks for people who understand what it takes to build and run distributed systems - network, availability, data - and customer empathy. - The team needs to be focussed on taking the time do build robust software for operational excellence. - The technical skills were different at Rent the Runway - these would tend to be more full-stack engineers who worked in a more iterative way. - Much of what we do at work is really about human relationships. One thing about relationships is that they tend to be better when you have one on one conversations with people on our regular basis. A lot of the value of one on one meeting is that you are reenforcing the social connection you have with the other person. - One of the most important things we do as engineering managers is stay abreast of how to make teams effective in the context of delivering software. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2RJdwYR You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2RJdwYR

On this week’s podcast, Wes Reisz talks to Emmanuel Ameisen, head of AI for Insight Data Science, about building a semantic search system for images using convolution neural networks and word embeddings, how you can build on the work done by companies like Google, and then explores where the gaps are and where you need to train your own models. The podcast wraps up with a discussion around how you get something like this into production. Why listen to this podcast: - A common use case is the ability to search for similar things - I want to find another pair of sunglasses like these, or I want a cat that looks like this picture, or even a tool like Google’s Smart Reply, can all be considered broadly the domain of semantic search. - For image classification you generally want a convolutional neural network. You typically use a model pre-trained with a public data set like Imagenet pre-trained to generate embeddings, using the pre-trained model up to the penultimate layer, and storing the value of the activations. - From here the idea is to mix image embeddings with word embeddings. The embeddings, whether for words or images, are just a vector that represents a thing. There are many approaches to getting vectors for words, but the one that started it is word2vec. - For both image embeddings and word embeddings you can typically use pre-trained models, meaning that you only need to train the final step of bringing the two models together. - Before deploying to production it is important that you validate the model against biases such as sexism, typically using outside people to a carry out a through audit. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2RAEUrV You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2RAEUrV

On this week’s podcast, Wes Reisz talks with Ben Kehoe of iRobot. Ben is a Cloud Robotics Research Scientist where he works on using the Internet to allow robots to do more and better things. AWS and, in particular, Lambda is a core part of cloud enabled robots. The two discuss iRobot’s cloud architecture. Some of the key lessons on the podcast include: thoughts on logging, deploying, unit/integration testing, service discovery, minimizing costs of service to service calls, and Conway’s Law. Why listen to this podcast: - The AWS Platform, including services such as Kinesis, Lambda, and IoT Gateway were key components in allowing iRobot to build out everything they needed for Internet-connected robots in 2015. - Cloud-enabled Roombas talk to the cloud via the IoT Gateway (which is MQQT) and are able to perform large file uploads using mutually authenticated certificates signed via an iRobot Certificate Authority. The entire system is event-driven with lambda being used to perform actions based on the events that occur. - When you’re using serverless, you are using managed infrastructure rather than building your own. So that means, when they exist, you have to accept the limitations of the infrastructure. For example, until recently Lambda didn’t have an SQS integration. So because of that limitation, you have to have inventive ways to make things work as you want. - Serverless is all about the total cost of ownership. It’s not just about development time, but across on areas that need to support operating the environment. - iRobot takes an approach of unit testing functions locally but does integration testing on a deployed set of functions. A library called Placebo helps engineers record events sent to the cloud and then replay them for local unit tests. - For logging/tracing, iRobot packages up information that a function uses into a structured record that is sent to CloudWatch. They then pipe that into SumoLogic to be able to trace executions. Most of the difficulties that happen tend to happen closer to the edge. - iRobot uses Red/Black deployments to have a completely separate stack when deploying. In addition, they flatten (or inline) their function calls on deployment. Both of these techniques are used as cost optimization techniques to prevent lambdas calling lambdas when not needed. - Looking towards the future of serverless, there is still work to be done to offer the same feature set that more traditional applications can use with service meshes. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2NYsXNN You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2NYsXNN

Vaughn Vernon is thought-leader in the space of reactive software and Domain Driven Design (DDD). Vaughn has recently released a new open source project called vlingo. The platform is designed to support DDD at the framework and toolkit level. On today’s podcast, Vaughn discusses what the framework is all about, why he felt it was needed, and some of the design decisions made in developing the platform, including things like the architecture, actor model decisions, clustering algorithm, and how DDD is realized with the framework. Why listen to this podcast: - Vlingo is an open source system for building distributed, concurrent, event-driven, reactive microservices that supports (at the framework level) Domain Driven Design. - The platform is in the early stages. It runs on the JVM. There is a port to C#. All code is pushed up stream. - The platform uses the actor model and all messages are sent in a type-safe way. - Vlingo supports clustering and uses a bully algorithm to achieve consensus. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2MwEWxb You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2MwEWxb

On today’s podcast, Justin Cormack discusses how the modern operating system is being decomposed with toolkits and libraries such as LinuxKit, eBPF, XDP, and what the kernel space service mesh Cilium is doing. Wes Reisz and Justin Cormack also discuss how Cilium differs from service meshes like an Istio, Linkerd2 (previously Conduit), or Envoy. Justin is a systems engineer at Docker. He previously was working with unikernels at Unikernel Systems in Cambridge before being acquired by Docker. (edited) *Key Takeaways:* * LinuxKit is an appliance way of thinking about your operating system and is gaining adoption. There are contributions now from Oracle, Cloudflare, Intel, etc. Docker has seen interesting use cases such as customers running LinuxKit on large cloud providers directly on bare metal (more on this coming soon). * The operating system of today is really unchanged since the Sun workstation of the 90’s. Yet everything else about software has really changed such as automation, build pipelines, and delivery. * XDP (eXpress Data Path) is a packet processing layer for Linux that lets you run fast in kernel compiled safe program in kernel called eBPF. It’s used for things like packet filtering and encapsulation/decapsulation. * Cilium is an in-kernel, high performance service mesh that leverages eBPF. Cilium is very good at layer 4 processing, but doesn’t really do the layer 7 things that some of the other services meshes can offer (such as proxying http/1 to http/2)

Probabilistic Programming has been discussed as a programming paradigm that uses statistical approaches to dealing with uncertainty in data as a first class construct. On today’s podcast, Wes talks with Mike Lee Williams of Cloudera’s Fast Forward Labs about Probabilistic Programming. The two discusses how Bayesian Inference works, how it’s used in Probabilistic Programming, production-level languages in the space, and some of the implementations/libraries that we’re seeing. Key Takeaways * Federated machine learning is an approach of developing models at an edge device and returning just the model to a centralized location. By taking the averages of the edge models, you can protect privacy and distribute processing of building models. *Probabilistic Programming is a family of programming languages that make statistical problems easier to describe and solve. *It is heavily influenced by Bayesian Inference or an approach to experimentation that turns what you know before the experiment and the results of the experiment into concrete answers on what you should do next. * The Bayesian approach to unsupervised learning comes with the ability to measure uncertainty (or the ability to quantify risk). * Most of the tooling used for Probabilistic Programming today is highly declarative. “You simply describe the world and press go.” * If you have a practical, real-world problem today for Probabilistic Programming, Stan and PyMC3 are two languages to consider. Both are relatively mature languages with great documentation. * Prophet, a time-series forecasting library built at Facebook as a wrapper around Stan, is a particularly approachable place to use Bayesian Inference for forecasting use cases general purpose.

Wes Reisz sits down and chats with Uncle Bob about The Clean Architecture, the origins of the Software Craftsperson Movement, Livable Code, and even ethics in software. Uncle Bob discusses his thoughts on how The Clean Architecture is affected by things like functional programming, services meshes, and microservices. Why listen to this podcast: * Michael Feathers wrote to Bob and said if you rearrange the order of the design principles, it spells SOLID. * Software Craftsperson should be used when you talking about software craftsmanship in a gender-neutral way to steer clear of anything exclusionary. * Clean Architecture is a way to develop software with low coupling and is independent of implementation details. * Clean Architecture and Domain Driven Design (DDD) are compatible terms. You would find the ubiquitous language and bounded context of DDD at the innermost circles of a clean architecture. * Services do not form an architecture. They form a deployment pattern that is a way of decoupling and therefore has no impact on the idea of clean architecture. * There is room for “creature comforts” in a code base that makes for more livable, convenient code. * “We have no ethics that are defined [in software].” If we don’t find a way to police it ourselves, governments will. We have to come up with a code of ethics. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2Nebspj You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2Nebspj

Arun Gupta discusses with Wes Reisz some of the container-focused services that AWS offers, including differentiating ECS and EKS. Arun goes into some detail the role that Amazon Fargate plays and goals behinds EKS. Arun wraps ups discussing some of the open source work that AWS has recently been doing in the container space. Why liste to this podcast: - ECS & EKS are both managed control planes; Amazon Fargate is a technology used to provision clusters. - ECR is the Amazon Container registry (similar to the Docker Registry). - EKS is an opinionated why of running a Kubernetes cluster on AWS. It is a highly available managed control plane available on US East 1 and US West 2 - EKS uses a split account. The control plane runs in an Amazon account and the workers run in customer’s account. - Upstream compatibility is a core tenant of EKS. You can subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2tWT8t9

In this podcast Wes Reisz is talking to Anastasiia Voitova, known as @vixentael in the security communities. She started her career as a mobile application developer, and in recent years has moved to focus mainly on designing and developing graphics software. We’re going to talk about cryptography, how to design libraries to be usable by developers, and designing cryptographic libraries. We’ll also discuss about her talk from the recent QCon New York , called “Making Security Usable”. Why listen to this podcast: - Choosing a good encryption algorithm isn’t enough - the parameters need to be chosen carefully as well - Algorithms like MD5 should not be used for hashing any more - Security is not just the encryption layer - it is the design of the whole system - Backups should be encrypted as well - Logs may contain sensitive GDPR data and need to be processed accordingly More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2yRWdQc You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2yRWdQc

On today’s podcast, Wes Reisz talks to Matt Klein about Envoy. Envoy is a modern, high performance, small footprint edge and service proxy. While it was originally developed at Lyft (and still drives much of their architecture), it is a fully open source driven project. Matt addresses on this podcast what he sees as the major design goals of Envoy, answers questions about a sidecar performance impact, discusses observability, and thinks out loud on the future of Envoy. Why listen to this podcast: - Envoy’s goal is to abstract the network from application programmers. It’s really about helping application developers focus on building business logic and not on the application plumbing. - Envoy is a large community driven project, not a cohesive product that does one thing. It can be used as a foundational building blocks to extend into a variety of use cases, including as an edge proxy, as a service mesh sidecar, and as a substrate for building new products. - While there is performance cost for using sidecar proxies, the rich featureset is often a worthwhile tradeoff. With that said, there is work being done that is greatly improving Envoy’s performance. - Envoy is built to run Lyft. There were no features that were in Envoy when it was open sourced that were not used at Lyft. - Envoy emits a rich set of logs and has a plugable tracing system. The goal is observability first and one of the main project goals. - Lyft deploys Envoy master twice per week. - Envoy’s roadmap includes work on automating settings (rate limits and retries), focus on ease of operation (such as where things got routed what the internal timings), and additional protocol support such as Kafka. You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2tmUKMl

On this podcast, Pam Selle (an engineer for IOPipe who builds tooling for serverless observability) talks about the case for serverless and the challenges for developing observability solutions. Some of the things discussed on the podcast include tips for creating boundaries between serverless and non-serverless resources and how to think of distributed tracing in serverless environments. Why listen to this podcast: - Coca Cola was able to see a productivity gain of 29% by adopting serverless (as measured by the amount of time spent on business productivity applications). - Tooling for serverless is often a challenge because resources are ephemeral. To address the ephemeral nature of serverless, you need to think about what information you will need to log ahead of time. - Monitoring should focus on events important to the business. - Build barriers between serverless and flat scaling non-serverless resources to prevent issues. Queues are an example of ways to protect flat scaling resources. - In-memory caches are a handy way to help serverless functions scale when fronting databases. - There are limitations with tracing and profiling on serverless. Several external products are available to help. - Serverless (and Microservices) are not for every solution. If you are choosing between two things, and one of them lets you ship and the other does not choose the thing that lets you ship. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2Jc6FXc You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. https://bit.ly/2Jc6FXc Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2Jc6FXc

The Serverless Framework is quickly becoming one of the more popular frameworks used in managing serverless deployments. David Wells, an engineer working on the framework, talks with Wes Reisz about serverless adoption and the use of the open source Serverless Framework. On this week’s podcast, the two dive into what it looks like to use the tool, the development experience, why a developer might want to consider a tool like the serverless framework, and finally wraps up with what the tool offers in areas like CI/CD, canaries, and blue/green deployment. Why listen to this podcast: - Serverless allows you to focus on the core business functionality and less on the infrastructure required to run your systems. - Serverless Framework allows you to simplify the amount of configuration you need for each cloud provider (for example, you can automate much of the configuration required for CloudFormation with AWS) - Serverless Framework is an open source CLI tool that supports all major cloud providers and several on-prem solutions for managing serverless functions. - The serverless space has room to grow in offering a local development space. Much of the workflow today involves frequent deploy and scoping the deployment for different stages. - Serverless Framework is open source and invites contributions from the community. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2IWayeE You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2IWayeE

In this podcast Wes Reisz talks to Colin Eberhardt, the Technology Director at Scott Logic, talks about what WebAssembly (WASM) is, a bit of the history of JavaScript, information about WebAssembly, and plans for WebAssembly 2.0 including the threading model and GC. Why listen to this podcast: - WebAssembly brings another kind of virtual machine to the browser that is a much more low-level language. - One of the goals of WebAssembly is to make a new assembly language that is a compilation target for a wide range of other languages such as C++, Java, C# and Rust. C++ is highly mature, Rust is maturing rapidly. Java and C# are a little further behind because of the lack of garbage collection support in WebAssembly. At some point in the future WebAssemblywill have it’s own garbage collection perhaps by using the Javascript garbage collector. - At runtime you use JavaScript to invoke functions that are exported by your WebAssembly instance. It should be noted that at the moment there is quite a lot of complexity involved in interfacing between WebAssembly and JavaScript. A lot of this complexity comes from the type system. - WebAssembly only supports four types - 2 integer types and 2 floating point types. To model strings you share the same piece of linear memory - memory that can read from and write to from both WebAssembly and JavaScript. - WebAssembly is still a very young technology. Future plans include threading support, garbage collection support, multiple value returns. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2G8QtzB You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2G8QtzB

Martin Thompson discusses consensus in distributed systems, and how Aeron uses Raft for clustering in the upcoming release. Martin is a Java Champion with over 2 decades of experience building complex and high-performance computing systems. He is most recently known for his work on Aeron and Simple Binary Encoding (SBE). Previously at LMAX he was the co-founder and CTO when he created the Disruptor. * Aeron is a messaging system designed for modern multi-core hardware. It is highly performant with a first class design goal of making it easy to monitor and understand at runtime. The product is able to simultaneously achieve the lowest latency and highest throughput of any messaging system available today. Why listen to this podcast: * Aeron uses a binary format on the wire rather than a text based protocol. This is largely done for performance reasons. Text is commonly used in messaging to make debugging simpler but the debugging problem can be solved using tools like Wireshark and the dissectors that come with it. * In a forthcoming release of Aeron will support clustering. Raft was chosen over PAXOS for this since it is more strict. This means that there are fewer potential states the system can be in making it easier to reason about. * RAFT is an RPC-based protocol, expecting synchronous interactions. Aeron is asynchronous by its nature, but the underlying Aeron protocol was designed to support consensus, meaning that a lot of things which would typically need to be done synchronously can be done asynchronously and/or in parallel. * Static clusters will be added first to Aeron, with dynamic clustering after that, and then cryptography again with the intention of keeping the latency and throughput high. (edited) More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2Ilewk5 You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2Ilewk5

In this podcast, recorded live at QCon.ai, Principal Technical Advisor & QCon Chair Wes Reisz and InfoQ Editor-in-chief Charles Humble chair a panel discussion with Stephanie Yee, data scientist at StitchFix, Matei Zaharia, professor of computer science at Stanford and chief scientist at Data Bricks, Sid Anand, chief data engineer at PayPal, and Soups Ranjan, director of data science at CoinBase. Why listen to this podcast: - Before you start putting a data science team together make sure you have a business goal or question that you want to answer; If you have a specific question, like increasing lift on a metric, or understanding customer usage patterns, you know where you can get the data from, and you can then figure out how to organise that data. - You need to make sure you have the right culture for the team - and find people who are excited about solving the business problems and be interested in it. Also look at the environment you are going to provide. - Your first hire shouldn’t be a data scientist (or quant). You need support to productionise the models - and if you don’t have a colleague to help productionise it then don’t hire the quant first. - Given the scarcity of talent it is worth remembering that Data Scientists come from a variety of different backgrounds - Some people have computer science backgrounds, some may be astrophysicists or neuroscientists who approach problems in different ways. - There are two common ways to structure a data science team: one is a vertical team that does everything, the other, more common in large companies, is when you have a separate data science team and an infrastructure team. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2Jym1RI You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2Jym1RI

On this week’s podcast, Danny Yuan, Uber’s Real-time Streaming/Forecasting Lead, lays out a thorough recipe book for building a real-time streaming platform with a major focus on forecasting. In this podcast, Danny discusses everything from the scale Uber operates at to what the major steps for training/deploy models in an iterative (almost Darwinistic) fashion and wraps with his advice for software engineers who want to begin applying machine learning into their day-to-day job. Why listen to this podcast: * Uber processes 850,000 - 1.3 million messages per second in their streaming platform with about 12 TB of growth per day. The system’s queries scan 100 million to 4 billion documents per second. * Uber’s frontend is mobile. The frontend talks to an API layer. All services generate events that are shuffled into Kafka. The real-time forecasting pipeline taps into Kafka to processes events and stores the data into Elasticsearch. * There is a federated query layer in front of Elasticsearch to provide OLAP query capabilities. * Apache Flink’s advanced windowing features, programming model, and checkpointing convinced Uber to move away from the simplicity of Apache Samza. * The forecasting system allows Uber to remove the notion of delay by using recent signals plus historical data to project what is happening now and what will happen into the future. * Uber’s pipeline for deploying ML models: HDFS, feature engineering, organizing into data structures (similar to data frames), deploy mostly offline training models, train models, & store into a container-based model manager. * A model serving layer is used to pick which model to use, forecasting results are stored in an OLAP data store, a validation layer compares real results against forecast results to verify the model is working as desired, and a rollback feature enables poor performing models to be automatically replaced by previous one. * “Without output, you don’t have input.” If you want to start leveraging machine learning, developers just need to start doing. Start with intuition and practice. Over time ask questions and learn what you need, then apply a laser focus to gain that knowledge. You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2GJQbUo

Sander Mak and Wes Reisz discuss the Java module system and how adoption is going. Topics discussed on this podcast include Java modularity steps / migrations, green field projects, some of the concerns that caused the EC to initially vote no on Java 9, and a new tool for building custom JREs called JLink. Additionally, as Java 10 was recently released a short bit at the end was added to discuss some of the latest news with Java. Why listen to this podcast: • People quickly moved to Java 8 because of features like Streams and Lambdas. Java 9 has a different story around modularity and application architecture. Adoption is slower and more intentional. • Migrating large codebases to use modularity is hard. Many of the projects using modules are greenfield, and those large codebases that are moving now are most often using the classpath. • Jlink is a new command line tool released with Java 9. It allows developers to create their own lightweight, customized JRE for a module-based Java application. • Java version scheme has dropped the 1.* prefix. Future releases of the JDK will have the version number and follow the form *.0.1 (i.e. 9.0.1) • While the module system will likely show it’s benefit mostly for new development, many 3rd party libraries are moving to adopt modularity and removing their dependencies on JDK internal APIs. It’s improving the experience for teams adopting modularity. • There are no known open JEPS regarding the enhancement of the Java module system. • Java 10 has been released. The release features changes to the freely available Java versions, local variable type inference (var), experimental GRAAL JIT compiler, application class data sharing, improved container support/awareness, and others. More on this: Quick scan our curated show notes on InfoQ https://bit.ly/2DQ7ptx You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: https://bit.ly/2DQ7ptx

Jendrik Joerdening and Anthony Navarro describe how a team of 18 Udacity students entered a self-racing car event They had very limited experience of building autonomous control systems for vehicles and had just 6 weeks to do it with only 2 days with the physical car. They describe the architecture, how they co-ordinated a very diverse team, and how they trained the models. Why listen to this podcast: - Last year a team of 18 Udacity Self-Driving Cars students competed at the 2017 Self Racing Cars event held at Thunderhill Raceway in California. - The students had all taken the first term of a three term program on Udacity which covers computer vision and deep learning techniques. - The team was extremely diverse. They co-ordinated the work via Slack with a team in 9 timezones and 5 different countries. - The team developed a neural network using Keras and Tensorflow which steered the car based on the input from just one front-facing camera in order to navigate all turns on the racetrack. - They received a physical car two days before the start of the event. More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2DykAiJ You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: http://bit.ly/2DykAiJ

On this podcast, we talk with Andrea Magnorsky, who is a tech lead at Goodlord on their engineering squads; she has a background in Scala, C#, and organised conferences. Today we’ll be talking about paradigm shifts. Why listen to this podcast: * A programming paradigm has a loose definition. It’s just about finding a way of doing things. * There are a number of different ways to think about problems - and different paradigms do this in different ways. * To shift paradigms, you have to un-learn some of your instincts. * When adopting a new paradigm if people don’t want to learn anything, then they won’t. * Multiple paradigms help you apply different ways of thinking about solutions to problems because solutions vary across languages. * Quick ways to start gaining knowledge and adoption for new languages are to use a new language as a test harness for your existing code. More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2oPFG71 You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: http://bit.ly/2oPFG71

On this podcast, Anne Currie joins the tech ethics discussion started on the Theo Schlossnagle podcast from a few weeks ago. Wes Reisz and Anne discuss issues such as the implications (and responsibilities) of the massive amount of scale we have at our fingertips today, potential effects of GDPR (EU privacy legislation), how accessibility is a an example of how we could approach tech ethics in software, and much more. Why listen to this podcast: - Ethics in software today is particularly important because of the scale we have available with cloud native architectures. - Accessibility offers a good approach to how we can evolve the discussion on tech ethics with aspects that include both a carrot and a stick. - Bitcoin mining power consumption is an example of something we never considered to have such negatives. - The key to establishing what we all should and shouldn’t be doing with tech ethics is to start conversations and share our lessons with each other. If you want to find out what every software developer, data scientists or ops should know about GDPR, download our free guide "Perspectives on GDPR": https://bit.ly/2FRvLnP More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2FtgdIy You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: http://bit.ly/2FtgdIy

This week on The InfoQ Podcast Wes Reisz talks with the CTO of Bouyant Oliver Gould. Bouyant is the maker the LinkerD Service Mesh and the recently released Conduit. In the podcast, Oliver defines a service mesh, clarifies the meaning of the data and control plane, discusses what a Service Mesh can offer a Microservice application owners, and, finally, discusses some of the considerations they took into account developing Conduit. Why listen to this podcast: - Service mesh is dedicated infrastructure that handles interservice communication. - There are two components to a service mesh: the data plane handles communication and the control plane is about policy and config. - LinkerD and Conduit are two open service meshes made by Bouyant. Conduit has a small memory footprint and provides a convention over configuration approach to service mesh deployment. - Adopting Rust (language used for implementing the data plane in Conduit) requires thinking of memory differently, and the best way to adopt Rust is to read other people’s code. More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2skWF61 You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: http://bit.ly/2skWF61

This week's podcast features a chat with Theo Scholossnagle. Theo is the CEO of Circonus and co-chairs the ACM Queue. In this podcast, Theo and Wes Reisz chat about the need for ethical software, and how we as technical leaders should be reasoning about the software we create. Theo says, "it's not about the absence of evil, it's about the presence of good." He challenges us to develop rigor around ethical decisions we make in software just as we do for areas like security. With the incredible implications of machine learning and AI in our future, this week's podcast touches on topics we should all consider in the systems we create. Why listen to this podcast: - The ubiquitous society impact of computers is surfacing the need for deeper conversations on software ethics. - Ethics are a set of constructs and constraints to help us reason about right and wrong. - Algorithmic interpretability of models can be difficult to reason about; however, accountability for algorithms can be enforced in other ways. - Questions to be considered when writing software should evolve into: What am I building, why am I building it, and who will it hurt? - Ethics in software will take industry reform, deeper conversations, and developing a culture of questioning the software we’re building More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2BZAC4p You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: http://bit.ly/2BZAC4p

On this week’s podcast, Wes Reisz talks with Chris Swan. Chris is the CTO for the global delivery organisation at DXC Technology. Chris is well versed in DevOps, Infrastructure, Culture, and what it means to put all these together. Today’s topics include both DevOps and NoOps, and what Chris calls LessOps, what Operations means in a world of Serverless, where he sees Configuration Management, Provisioning, Monitoring and Logging heading. The podcast then wraps talking about where he sees validating code in a serverless deployment, such as canaries and blue-green deployments. Why listen to this podcast: * Serverless still requires ops - even if the ops aren’t focused on the technology * Even with minimal functions, the amount of configuration may exceed it by a factor of three * Disruptive services often move the decimal point * ML is the ability to make the inferences and AI is the ability to make decisions based on those inferences More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2Bff4jU You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: http://bit.ly/2Bff4jU

This week’s podcast features a chat with Vitor Olivier. Vitor is a partner at NuBank (a technology-centric bank in Brazil). This podcast hits on topics from several of Nubank’s recent QCon talks and includes things like: Nubank’s stack, functional programming, event sourcing, defining service boundaries, recommendations on reasoning about services, tips (or tweaks) on the second iteration of their initial architecture and more. Why listen to this podcast: - Property-based testing and Schemas (or Clojure.Spec)are complementary. - Clojure’s functional nature and Datomic’s features are a match for Nubank’s requirements. - A (micro)service needs to be able to create the full representation of the core feature it’s handling. - GraphQL is useful to abstract away the distributed system complexity from the mobile (or frontend) developers. - Nubank’s uses a combination of monitoring and sanity checks in real time at various level to keep systems consistent. - Once an invariant is broken, the system will try to fix it automatically. More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2mnqyfK You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Check the landing page on InfoQ: http://bit.ly/2mnqyfK

In this podcast Charles Humble and Wes Reisz talk about Java 9 and beyond, Kotlin, .NET Core 2, the surge in interest in organisational culture, quantum computing and more. Why listen to this podcast: - Java had a big year with Java 9 shipping, Java EE going open-source and moving to Eclipse as EE4J, and IBM open-sprucing J9. From next year the platform will also be on a bi-annual release cycle with the next two versions (expected to be Java 10 and 11) both shipping during 2018. - Kotlin joined Scala, Clojure, and Groovy as a strong alternative language for the JVM particularly for mobile where it was buoyed by Google’s official blessing of it as a language for Android development at Google IO. - On InfoQ we also saw a big surge in interest around .NET linked to .NET Core 2, and at both InfoQ and at QCon San Fransisco we also saw an upsurge in interest around organizational culture with one of the culture tracks (the Whole Engineer) moving to one of the larger rooms. - We started to see Quantum computers emerging from the labs, with IBM making a 16 Qbit quantum processor available via their cloud for developers to play with, and the corresponding library available for Python on Github, - Another major trend from the year was the availability of machine learning libraries for software developers to build and train models Check the landing page on InfoQ: http://bit.ly/2ljlBVH Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq

Gremlin is a Software as a Service that lets you plan, control and undo Chaos engineering experiments built by engineers with experience from Netflix, AWS, Dropbox and others. In this podcast Wes talks to Kolton Andrus about the Gremlin product and architecture and related topics such as running Game Days. You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq

In this podcast, Deam Wampler discusses fast data, streaming, microservices, and the paradox of choice when it comes to the options available today building data pipelines. Why listen to this podcast: * Apache Beam is fast becoming the de-facto standard API for stream processing * Spark is great for batch processing, but Flink is tackling the low-latency streaming processing market * Avoid running blocking REST calls from within a stream processing system - have them asynchronously launched and communicate over Kafka queues * Visibility into telemetry of streaming processing systems is still a new field and under active development * Running the fast data platform is easily launched on an existing or new Mesosphere DC/OS runtime More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2BYTMbI You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Want to see extented shownotes? Check the landing page on InfoQ: http://bit.ly/2BYTMbI

In this podcast, Werner Schuster talks to Changhoon Kim, who is a Director of System Architecture at Barefoot Networks, and is actively working for the P4 language consortium. They talk about the new PISA (protocol independence switch architecture) which promises multi-terabit switching, and P4, a domain-specific programming language designed for networking. You can subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq

In this podcast, we are talking to Tyler Akidau, a senior engineer at Google, who leads the technical infrastructure and data processing teams in Seattle, and a founding member of the Apache Beam PMC and a passionate voice in the streaming space. This podcast will cover data streaming and the 2015 DataFlow Model streaming paper [http://www.vldb.org/pvldb/vol8/p1792-Akidau.pdf] and much of the concepts covered, such as why dealing with out-of-order data is important, event time versus processing time, windowing approaches, and finally preview the track he is hosting at QConf SF next week. Why listen to this podcast: - Batch processing and streaming aren’t two incompatible things; they are a function of different windowing options. - Event time and processing time are two different concepts, and may be out of step with each other. - Completeness is knowing that you have processed all the events for a particular window. - Windowing choice can be answered from the what, when, where, how questions. - Unbounded versus bounded data is a better dimension than stream or batch processing. More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2AyBTAb You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Want to see extented shownotes? Check the landing page on InfoQ: http://bit.ly/2AyBTAb

In this podcast, Wes talks to Guy Podjarny (Founder/CEO Synk). The two discuss the space between open source software and third-party dependencies, including a discussion of the Equifax hack (and what we can learn from it), the role of serverless architectures today (and what it means to application surface area), and then finally they wrap with security hygiene best practices with OSS and serverless. Why listen to this podcast: - The majority of security vulnerabilities that exist in applications today comes from vulnerable third-party libraries, rather than the application’s own code. - An application shouldn’t permit total leak of all data because of a single vulnerability - defence in depth is important. - Equifax couldn’t have failed more spectacularly in the way they handled it. - The Equifax hack serves as a wake-up call to pay attention to vulnerabilities in dependencies. - If your build system breaks the build when a dependency vulnerability is found automatically, it will be applied sooner. More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2ziAIat You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Want to see extented shownotes? Check the landing page on InfoQ: http://bit.ly/2ziAIat

In this podcast, QCon Chair Wesley Reisz talks to Julien Viet. Viet is the project lead for Vert.x and a principal engineer at RedHat having taken over as project lead for Vert.x from Tim Fox in January 2016. They talk about the newly released Vert.x 3.5.0, and the plans for Vert.x 4.0. Why listen to this podcast: * Vert.x adds RxJava2 support for streams and backpressure. * Vert.x is a polyglot set of APIs, custom aligned for the specific language. * It is unopinionated and can be used with any environments, since it doesn’t enforce a particular framework. * Verticles communicate in-VM or through peer-to-peer networking for distributed applications. * Vert.x 4.0 is on the roadmap for the future. More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2z0BEQR You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Want to see extented shownotes? Check the landing page on InfoQ: http://bit.ly/2z0BEQR

What can software learn from industries like aerospace, transportation, or even retail during national disasters? This week’s podcast is with Emil Stolarsky and was recorded live after his talk on the subject at Strangeloop 2017. Interesting points from the podcast include several stories from Emil’s research, including the origin of the checklist, how Walmart pushed decision making down to the store level in a national disaster, and where the formalized conversation structure onboard aircraft originated. The podcast mentions several resources you can turn to if you want to learn more and wraps with some of the ways this research is affecting incident response at Shopify. Why listen to this podcast: * Existing industries like aerospace have built a working history of how to resolve issues; it can be applicable to software issues as well. * Crew Resource Management helps teams work together and take ownership of problems that they can solve, instead of a command-and-control mandated structure. * Checklists are automation for the brain. * Delegating authority to resolve system outages removes bottlenecks in processes that would otherwise need managerial sign off. * When designing an alerting system, make sure it doesn’t flood with irrelevant alerts and that there’s clear observability to what is going wrong. More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2zmCsfR You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Want to see extented shownotes? Check the landing page on InfoQ: http://bit.ly/2zmCsfR

In this podcast, recorded live at Strange Loop 2017, Wes talks to Charity, cofounder and CEO of honeycomb.io. They discuss the social side of debugging and her Strange Loop talk “Observability for Emerging Infra: What got you Here Won't get you There”. Other topics include advice for testing in production, shadowing and splitting traffic, and sampling and aggregation. Why listen to this podcast: - Statistical sampling allows for collecting more detailed information while storing less data, and can be tuned for different event types. - Testing in production is possible with canaries, shadowing requests, and feature switches - Pulling data out of systems is just noise - it becomes valuable once someone has looked at it and indicates the meaning behind it. - Instrumenting isn’t just about problem detection - it can be used to ask business questions later - You can get 80% of the benefit from 20% of the work in instrumenting the systems. More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2y6OP1b You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq Subscribe: www.youtube.com/infoq Like InfoQ on Facebook: bit.ly/2jmlyG8 Follow on Twitter: twitter.com/InfoQ Follow on LinkedIn: www.linkedin.com/company/infoq Want to see extented shownotes? Check the landing page on InfoQ: http://bit.ly/2y6OP1b