The InfoQ Podcast

Latest Episodes:

Neha Batra - Pivotal Labs Pair Programming Jan 06, 2017

Show notes

In this week’s podcast Wes Reisz talks to Neha Batra, a software engineer at Pivotal Labs. Neha spoke about pair programming in her recent QCon San Francisco 2016 presentation, and has taken time to discuss techniques to get started with the practice as well as tips for implementing it on your team. Neha also touches on vulnerability based trust and how it can help effectively build a trusting team environment. Why listen to this podcast: - If you successfully start with pair programming, other tenants of XP are pulled along with you - Ways to get creative with remote pairing to make it work - The daily retro - Overcoming hesitance with managers when trying to implement pair programming full time - Vulnerability based trust building Notes and links can be found on: http://bit.ly/2i2a0sJ How has Pair Programming Evolved Over the Years? 6m:17s - A lot of the fundamentals are the same, but with XP we take it to the extreme to be able to do it eight hours a day. 6m:24s - To pair for eight hours a day we adapt to a lot of other process to create a simpler way of working, giving us an easier level to default to. 6m:44s - We use phrases in the team to make sure we agree on a test, that there are no false positives, when to refactor etc. This helps us avoid accruing code debt since we don’t do code reviews. More on this: Quick scan our curated show notes on InfoQ. http://bit.ly/2i2a0sJ You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Oliver Gould About Architecting to Avoid and Recover from Failure Dec 30, 2016

Show notes

In this week’s podcast, Robert Blumen talks to Oliver Gould at QCon San Francsico 2016. Oliver is the CTO of Buoyant where he leads open source development efforts. Prior to Buoyant he was a Staff Infrastructure Engineer at Twitter where he was technical lead on Observability, Traffic, Configuration and Co-ordination teams. Why listen to this podcast: - Stratification allows applications to own their logic while libraries take care of the different mechanisms, such as service discovery and load balancing - Cascading failures can’t be tested or protected against, so having a fast time to recovery is important - Having developers own their services with on-call mechanisms improves the reliability of the service; it’s best to optimise automatic restarts so problems can be addressed during normal working hours - Post mortem analysis of failures are important to improve run books or checklists and to share learning between teams - Incremental roll out of features with feature flags or weighted routing provides agility while testing with production load, which highlights issues that aren’t seen during limited developer testing Notes and links can be found on: http://bit.ly/2ivoz9w 4m:05s - Each domain has different failure and operating modes, and the layered approach to resiliency means that the layer handles this automatically 4m:30s - Large systems may fail in unexpected ways 4m:35s - Twitter originally had the “Fail Whale” but this has been phased out as the system has become more stable 4m:50s - As Twitter grew, it needed to move quicker, with more engineers and less whale time 5m:10s - Automation and social tools were needed to improve the situation More on this - Quick scan our curated show notes on InfoQ: http://bit.ly/2ivoz9w You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Chris Richardson on Domain-Driven Microservices Design Dec 23, 2016

Show notes

In this week’s podcast, Thomas Betts talks with Chris Richardson, a developer, architect, Java Champion and author of POJOs in Action. Before his workshop on Microservices w/ Spring Boot and Docker at QCon San Francisco 2016, Richardson took time to discuss his ideas on how to use DDD and CQRS concepts as a guide for implementing a robust microservices architecture. Why listen to this podcast: - "Microservice architecture" is a better term than "microservices". The latter suggests that a single microservice is somehow interesting - The concepts discussed in Domain-Driven Design are an excellent guide for how to implement a microservices architecture - Bounded Contexts correspond well to individual microservices - Event sourcing and CQRS provide patterns for how to implement loosely coupled services - When converting a monolith to microservices, avoid a big bang rewrite, in favor of an iterative approach Notes and links can be found on: http://bit.ly/2hZ8TM1 11m:51s - Microservices must be loosely coupled, usually creating a model with one database per service. 12m:45s - There is a business requirement to maintain data consistency across services, and using an event driven architecture is a good way to achieve that. 13m:38s - Event sourcing is specific technique for persisting domain objects as a series of events. 14m:11s - Just as transactions don’t like to be split across microservices, queries cannot simply join across multiple data sources. CQRS provides a solution that accommodates querying via microservices and materialized views. More on this: Quick scan our curated show notes on InfoQ. http://bit.ly/2hZ8TM1 You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Keith Adams on the Architecture of Slack, using MySql, Edge Caching, & the backend Messaging Server Dec 16, 2016

Show notes

In this week’s podcast, QCon chair Wesley Reisz talks to Keith Adams, chief architect at Slack. Prior he was an engineer at Facebook where he worked on the search type live backend, and is well-known for the HipHop VM [hhvm.com]. Adams presented How Slack Works at QCon SanFrancisco 2016. Why listen to this podcast: - Group messaging succeeds when it feels like a place for members to gather, rather than just a tool - Having opt-in group membership scales better than having to define a group on the fly, like a mailing list instead of individually adding people to a mail - Choosing availability over consistency is sometimes the right choice for particular use cases - Consistency can be recovered after the fact with custom conflict resolution tools - Latency is important and can be solved by having proxies or edge applications closer to the user Notes and links can be found on: http://bit.ly/keith-adams 3m:30s Voice and video interactions are impacted by latency; the same is true of messaging clients 4m:00s The user interface can provide indications of presence, through avatars indicating availability and typing indicators 4m:15s Latency is important; sometimes the difference is between 100ms and 200ms so the message channel monitors ping timeout between server and client 4m:40s 99th percentile is less than 100ms ping time 5m:15s If the 99th percentile is more than 100ms then it may be server based, such as needing to tune the Java GC 5m:25s Network conditions of the mobile clients are highly variable 6m:20s Mobile clients can suffer intermittent connectivity More on this: Quick scan our curated show notes on InfoQ. http://bit.ly/keith-adams You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Haley Tucker on Responding to Failures in Playback Features at Netflix Dec 09, 2016

Show notes

In this week’s podcast, Thomas Betts talks with Haley Tucker, a Senior Software Engineer on the Playback Features team at Netflix. While at QCon San Francisco 2016, Tucker told some production war stories about trying to deliver content to 65 million members. Why listen to this podcast: - Distributed systems fail regularly, often due to unexpected reasons - Data canaries can identify invalid metadata before it can enter and corrupt the production environment - ChAP, the Chaos Automation Platform, can test failure conditions alongside the success conditions - Fallbacks are an important component of system stability, but the fallbacks must be fast and light to not cause secondary failures - Distributed systems are fundamentally social systems, and require a blameless culture to be successful Notes and links can be found on: http://bit.ly/2hqzQ6K 2m:05s - The Video Metadata Service aggregates several sources into a consistent API consumed by other Netflix services. 2m:43s - Several checks and validations were in place within the video metadata service, but it is impossible to predict every way consumers will be using the data. 3m:30s - The access pattern used by the playback service was different than that used in the checks, and led to unexpected results in production. 3m:58s - Now, the services consuming the data are also responsible for testing and verifying the data before it rolls out to production. The Video Metadata Service can orchestrate the testing process. More on this: Quick scan our curated show notes on InfoQ. http://bit.ly/2hqzQ6K You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Kolton Andrus on Lessons Learnt From Failure Testing at Amazon and Netflix and New Venture Gremlin Dec 02, 2016

Show notes

In this week's podcast, QCon chair Wesley Reisz talks to Kolton Andrus. Andrus is the founder of Gremlin Inc. He was a Chaos Engineer at Netflix, focused on the resilience of the Edge services. He designed and built FIT: Netflix’s failure injection service. Prior, he improved the performance and reliability of the Amazon Retail website. Why listen to this podcast: - Gremlin, Kolton Andrus' new start-up, is focused on providing failure testing as a service. Version 1, currently in closed beta, is focused on infrastructure failures. - Lineage-driven Fault Injection (LDFI) allowed Netflix to dramatically reduce the number of tests they needed to run in order to explore a problem space. - You generally want to run failure tests in production, but you can't start there. Start in developemnt and build up. - Having failure testing at an application level, as Netflix does, so you can have request level fault injection for a specific user or a specific device. - Being able to trace infrastructure with something like Dapper or Zipkin offers tremendous value. At Netflix, the failure injection system is integrated into the tracing system, which meant that when they caused a failure they could see all the points in the system that it touched. More on this: Quick scan our curated show notes on InfoQ. http://bit.ly/2fT9YiM You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Preslav Le on How Dropbox Moved off AWS and What They Have Been Able to Do Since Nov 18, 2016

Show notes

As InfoQ previously reported in March 2016, Dropbox announced that they had migrated away from Amazon Web Services (AWS). In this week's podcast Robert Bluman talks to Preslav Le. Preslav has been a software engineer at Dropbox for the past three years, contributing to various aspects of Dropbox’s infrastructure including traffic, performance and storage. He was part of the core oncall and storage oncall rotations, dealing with high emergency real world issues, from bad code pushes to complete datacenter outages. Why listen to this podcast: - Dropbox migrated away from Amazon S3 to their own data centres to allow them to optimise for their specific use case. - They are experimenting with Shingled Magnetic Recording (SMR) drives for primary storage to increase storage density. All writes go to an SSD cache and then get pushed asynchronously to the SMR disk. - Their average block size is 1.6MB with a maximum block size of 4MB. Knowing this allows the team to tune their storage system. - Three languages are used for the backend infrastructure. Python is used mainly for business logic, Go is the primary language used for heavy infrastructure services, and in some cases, for example where more direct control over memory is needed, Rust is also used. - Dropbox invest very heavily in verification and automation. A verifier scans every byte on disk and checks that it matches the checksum in the index. - Verification is also used to check that each box has the block keys it should have. Notes and links can be found on http://bit.ly/preslav-le Dropbox’s motivation for moving off the cloud 2:40 - Dropbox used Amazon S3 and other services where it made sense, but they stored all the metadata in their own data centres. 3:30 - Initially this was done because Amazon had poor support for persistent storage at the time. This has since improved but it didn’t make sense for dropbox to move the metadata back. 4:01 - By that time the dropbox team was ready to tackle the storage problem and built their own in-house replacement for S3, called Magic Pocket. Magic Pocket allowed Dropbox to move away from Amazon altogether. 4:30 - The move saved money, but also allowed DropBox to optimise for their specific use case and be faster. More on this: Quick scan our curated show notes on InfoQ. http://bit.ly/preslav-le You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Randy Shoup on Stitch Fix's Technology Stack, Data Science and Microservices Nov 11, 2016

Show notes

In this week's podcast QCon chair Wesley Reisz talks to Randy Shoup. Shoup is the vice president of engineering at Stitch Fix. Prior to Stitch Fix, he worked for Google as the director of engineering and cloud computing, CTO and co-founder of Shopilly, and chief engineer at Ebay. Why listen to this podcast: - Stitch Fix's business is a combination of art and science. Humans are much better with the machines, and the machines are much better with the humans. - Stitch Fix has 60 engineers, with 80 data scientists and algorithm developers. This ratio of data science to engineering is unique. - With Ruby-on-Rails on top of Postgres, the company maintains about 30 different applications on the same stack. - The practice of Test Driven Development makes Continuous Delivery work, and the practice of having the same people build the code as those who operate the code makes both of these things much more powerful. - Microservices gives feature velocity, the ability for individual teams to move quickly and independently of each other, and independent deployments. - Microservices solve a scaling problem. They solve an organisational scaling problem, and a technological scaling problem. These are not the problems that you have early on in the startup. - In the monolithic world, if you're not able to continue to vertically scale the application or the database or whatever your monolith is. And so for scaling reasons alone you might consider breaking it up into what we call microservices. Notes and links can be found on http://bit.ly/randy-shoup-podcast Data Science and Stitch Fix 1m:57s - Stitch Fix re-imagines retail, particularly for clothing. When you sign up, you fill out survey of the kinds of things that you like and you don't like, and we choose what we think you're going to enjoy based on the millions of customers that we have already. And we use a ton of data science in that process. 3m:00s - That goes into our algorithms and then our algorithms make personalised recommendations based on all the things we know about our other customers... there's a human element as well: we have 3,200 human stylists that are all around the United States and they choose the five items that go into the box [of clothing]. 3m:29s - What we like is that this is a combination of art and science. Modern companies combine what machines are really good at, such as chugging through the 60 to 70 questions times the millions of customers, and combining that with the human element of the stylists, figuring out what things go together, what things are trending, what things are appropriate... Humans are much better with the machines, and the machines are much better with the humans. [...] More on this: Quick scan our curated show notes on InfoQ. http://bit.ly/randy-shoup-podcast You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Tal Weiss on Observability, Instrumentation and Bytecode Manipulation on the JVM Nov 04, 2016

Show notes

In this week's podcast, QCon chair Wesley Reisz talks to Tal Weiss, CEO of OverOps, recently re-branded from Takipi. The conversation covers how the OverOps product works, explores the difference between instrumentation and observability, discusses bytecode manipulation approaches and common errors in Java based applications. A keen blogger, Weiss has been designing scalable, real-time Java and C++ applications for the past 15 years. He was co-founder and CEO at VisualTao which was acquired by Autodesk in 2009, and also worked as a software architect at IAI Space Industries focusing on distributed, real-time satellite tracking and control systems. Why listen to this podcast: - OverOps uses a mixture of machine code instrumentation and static code analysis at deployment time to build up an index of the code - Observability is how you architect your code to be able to capture information from its outputs. Instrumentation is where you come in from the outside and use bytecode or machine code manipulation techniques to capture information after the system has been designed and built. - Bytecode instrumentation is a technique that most companies can benefit from learning a bit more about. Bytecode isn’t machine code - it is a high-level programming language. Being able to read it really helps you understand how the JVM works. - There are a number of bytecode manipulation tools you can use to work with bytecode - ASM is probably the most well known. - A fairly small number of events within an application’s life-cycle generate the majority of the log volume. A good practice is to regularly review your log files to consider if what is being logged is the right thing. Notes and links can be found on http://bit.ly/2fInGsW SaaS vs On-Premise 5:43 - OverOps started as a SaaS product, but given that a lot of the data it collects is potentially sensitive, they introduced a new product called Hybrid. Hybrid separates the data into two independent streams: data and metadata. 6:42 - The data stream is the raw data that is captured which is then privately encrypted using 256 bit AES encryption keys which are only stored on the production machine and by the user when they need to decrypt it. The metadata stream is not sensitive since it is just an abstract mathematical graph. 7:18 - Because the data stream is already privately encrypted, that stream can be stored behind a firewall and never needs to leave a company’s network. More on this: Quick scan our curated show notes on InfoQ. http://bit.ly/2fInGsW You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Cathy O'Neil on Pernicious Machine Learning Algorithms and How to Audit Them Sep 16, 2016

Show notes

In this week's podcast InfoQ’s editor-in-chief Charles Humble talks to Data Scientist Cathy O’Neil. O'Neil is the author of the blog mathbabe.org. She was the former Director of the Lede Program in Data Practices at Columbia University Graduate School of Journalism, Tow Center and was employed as Data Science Consultant at Johnson Research Labs. O'Neil earned a mathematics Ph.D. from Harvard University. Topics discussed include her book “Weapons of Math Destruction,” predictive policing models, the teacher value added model, approaches to auditing algorithms and whether government regulation of the field is needed. Why listen to this podcast: - There is a class of pernicious big data algorithms that are increasingly controlling society but are not open to scrutiny. - Flawed data can result in an algorithm that is, for instance, racist and sexist. For example, the data used in predictive policing models is racist. But people tend to be overly trusting of algorithms because they are mathematical. - Data scientists have to make ethical decisions even if they don’t acknowledge it. Often problems stem from an abdication of responsibility. - Auditing for algorithms is still a very young field with ongoing academic research exploring approaches. - Government regulation of the industry may well be required. Notes and links can be found on http://bit.ly/2eYVb9q Weapons of math destruction 0m:43s - The central thesis of the book is that whilst not all algorithms are bad, there is a class of pernicious big data algorithms that are increasingly controlling society. 1m:32s - The classes of algorithm that O'Neil is concerned about - the weapons of math destruction - have three characteristics: they are widespread and impact on important decisions like whether someone can go to college or get a job, they are somehow secret so that the people who are being targeted don’t know they are being scored or don’t understand how their score is computed; and the third characteristic is they are destructive - they ruin lives. 2m:51s - These characteristics undermine the original intention of the algorithm, which is often trying to solve big society problems with the help of data. More on this: Quick scan our curated show notes on InfoQ. http://bit.ly/2eYVb9q You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Our TOPPODCAST Picks

Follow Us

Stay Connected

Related Podcasts

Links

Stay Connected