tech

Summary: For our inaugural podcast QCon chair Wesley Reisz talks to Adrian Cockcroft, who works for Battery Ventures where he advises the firm and its portfolio companies about technology issues and also assists with deal sourcing and due diligence.
Why listen to this podcast
•	Over the last year a large number of frameworks and libraries for building microservices have emerged and we're seeing a lot of rapid change.
•	The stack you choose will often be based on the main language you use, so for example Netflix’s stack is language agnostic but the tooling is very Java-centric.
•	Architectural choices can have a profound impact on success, so some-thing as simple as an overly long timeout with retries can cause your system to suffer from a congestion collapse problem.  Have a large timeout at the edge, and progressively smaller and smaller timeouts as you get deeper into the system.
•	Start with a monolith and move to a distributed architecture when you need to because of team size or to get better separation of concerns.
•	Other disruptive trends include “serverless architecture” like AWS Lambda, and open source itself which is perhaps the true definition of disruptive.
More on this
•	You can access our in-depth coverage on microservices http://bit.ly/1SRnFz3.
•	You can also subscribe to our newsletter to receive weekly updates on the hottest topics from professional software development. http://bit.ly/24x3IVq
•	Attend Adrian Cockcroft 's session at QCon New York 2016, Jun 13-17. http://bit.ly/1TvzlDQ 


Show Notes

Adrian Cockcroft on Microservices, Terraservices and Serverless Computing

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

InfoQ Podcast

Kolton Andrus on Lessons Learnt From Failure Testing at Amazon and Netflix and New Venture Gremlin

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

Haley Tucker on Responding to Failures in Playback Features at Netflix

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&nbsp;
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

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

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

Chris Richardson on Domain-Driven Microservices Design

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

Oliver Gould About Architecting to Avoid and Recover from Failure

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

Neha Batra - Pivotal Labs Pair Programming

Jonas Bonér, CTO of LightBend and creator Akka, discusses using Akka when developing distributed systems. He talks about the Actor Model, and how every Microservice needs to be viewed as a system to be successful. 

Why listen to this podcast:

 - Akka is JVM-based framework design for developing distributed systems leveraging the Actor Model - an approach for writing concurrent systems that treat actors as universal primitives and the most successful model with abstraction has been streaming
 - Circuit breakers in Akka are a backup and retry policy; they protect you by capturing failure data and allow you to roll back 
 - Every Microservice needs to be viewed as a system, it needs to have multiple parts that run on different machines in order to function and be fully resilient - thus is a Microsystem
 - Two different trends have emerged when it comes to hardware and environments: one is the trend toward Multi-core, the is a movement toward virtualized environments and the cloud
 - Saga pattern of managing long running transactions in a distributed system fits very well with messaging style architectures

Notes and links can be found on: http://bit.ly/2kwB2eB

Akka
The Actor Model
When Akka and the Actor Model is the perfect choice
Circuit breakers patterns in distributed systems
Two trends toward Multi-core
Reactive Manifesto
Event Driven vs. Message Driven
Reactive Programming and Streams
Microliths to Microsystems
What do you have to get right before you start trying to deploy a distributed systems?
Working with ML / AI at Lightbend to understand tracing through distributed system
Saga Pattern

More on this:
Quick scan our curated show notes on InfoQ http://bit.ly/2kwB2eB

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

Jonas Bonér on the Actor Model, Akka, Reactive Programming, Microservices and Distributed Systems

Wesley Reisz talks to Daniel Bryant on moving from monoliths to micro-services, covering bounded contexts, when to break up micro-services, event storming, practices like observability and tracing, and more.

Why listen to this podcast:

- Migrating a monolith to micro-services is best done by breaking off a valuable but not critical part first.
 - Designing a greenfield application as micro-services requires a strong understanding of the domain.
 - When a request enters the system, it needs to be tagged with a correlation id that flows down to all fan-out service requests.
 - Observability and metrics are essential parts to include when moving micro-services to production.
 - A service mesh allows you to scale services and permit binary transports without losing observability.

More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2pFYBiT

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/2pFYBiT

Daniel Bryant on Microservices and Domain Driven Design

Wesley Reisz talks to Sachin Kulkarni, Director of Engineering at Facebook, about the engineering challenges for Facebook live, and how it compares to the video upload platform at Facebook.

Why listen to this podcast:

 - Facebook Infrastructure powers the board family of apps including the Facebook app, Messenger and Instagram.  It is largely a C++ shop.  There is some Java and Python, and the business logic is all done in PHP.  The iOS apps are written in Objective C and the Android apps are in Java.

 - The video infra team at Facebook builds the video infrastructure across the whole company.  Projects include a distributed video encoding platform which results in low latency video encoding, video upload and ingest.

 - Facebook Live does encoding on both the client and the server.  The trade-off between encoding on the client side and the server side is mostly around the quality of the video vs. latency and reliability.

 - Facebook gets around 10x speed-up by encoding data in parallel compared to serial.  

 - They also have an AI-based encoding system which resulted in 20% smaller files than raw H.264.

You can also subscribe to the InfoQ newsletter to receive weekly updates on the hottest topics from professional software development. bit.ly/24x3IVq

More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2qrseG5

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/2qrseG5

Want more? Read InfoQ: http://bit.ly/2dcHmpu

Sachin Kulkarni Describes the Architecture Behind Facebook Live

Wesley Reisz talks to Sid Anand, a data architect at cybersecurity company Agari, about building cloud-native data pipelines. The focus of their discussion is around a solution Agari uses that is built from Amazon Kinesis Streams, serverless functions, and auto scaling groups.

Sid Anand is an architect at Agari, and a former technical architect at eBay, Netflix, and LinkedIn.  He has 15 years of data infrastructure experience at scale, is a PMC for Apache Airflow, and is also a program committee chair for QCon San Francisco and QCon London.

Why listen to this podcast

 - Real-time data pipeline processing is very latency sensitive
 - Micro-batching allows much smaller amounts of data to be processed
 - Use the appropriate data store (or stores) to support the use of the dataIngesting data quickly into a clean database with minimal indexes can be fast
 - Communicate using a messaging system that supports schema evolution

More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2rJU9nB

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/2rJU9nB

Sid Anand on Building Agari’s Cloud-native Data Pipelines with AWS Kinesis and Serverless

Wesley Reisz talks with Jessica Kerr about her focus on developer productivity. Topics include her work at Atomist building Slack Chatbots, an approach to categorizing Yak Shaving (in an effort to prioritize and automate development dependencies), how an innovation culture drives diversity, and, finally, the role of 10x developers in the lifecycle of a company or product.

Why listen to this podcast:

 - There are five kinds of Yak to shave
 - Atomist uses a Slack chatbot to automate and track commits, builds, push requests etc.
 - Agile retrospectives are a great way to encourage an innovation culture
 - Diverse teams flourish in innovation cultures
 - 10x developers are great for launching products, but teams are needed as products scale up

More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2uO60PR

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/2uO60PR

Jessica Kerr on Productivity, Slack Chatbots, Yak Shaving, & Why Diversity Matters for Innovation

Wesley Reisz talks with Sam Newman about microservices.  They explore the current state of the art with regards the architectural style and corresponding tooling and deployment platforms. They then discuss how microservices increase the surface area of where sensitive information can be read or manipulated, but also have the potential to create systems that are more secure.

Why listen to this podcast:

 - Different organisations have different risk appetites for new technology, so what may be appropriate for one organisation may not be appropriate technology choices for another. 
 - If you are deploying micro services then you need to know why you are doing it and what benefits you expect to get from deploying them.
 - Micro services are defined by their independently deployable units rather than their size. 
 - Using a cryptographic token that is verifiable off line is a common pattern for passing authentication contexts around to different services.
 - Serverless architectures redeuce the need to monitor server patching but does not diminish the need for monitoring application runtime or library dependencies from security patching.

More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2v8NJg6

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/2v8NJg6

Security Considerations and the State of Microservices with Sam Newman

Nora Jones, a senior software engineer on Netflix’ Chaos Team, talks with Wesley Reisz about what Chaos Engineering means today. She covers what it takes to build a practice, how to establish a strategy, defines cost of impact, and covers key technical considerations when leveraging chaos engineering.

Why listen to this podcast:

- Chaos engineering is a discipline where you formulate hypotheses, perform experiments, and evaluate the results afterwards.
- Injecting a bit of failure over time is going to make your system more resilient in the end.
- Start with Tier 2 or non-critical services first, and build up success stories to grow chaos further.
- As systems become more and more distributed, there becomes a higher need for chaos engineering.
- If you’re running your first experiment, get your service owners in a war room and get them to monitor the results of the test as it is running.

More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2vJoimw

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 extended shownotes? Check the landing page on InfoQ: http://bit.ly/2vJoimw

Nora Jones on Establishing, Growing, and Maturing a Chaos Engineering Practice

This week's podcasts features Yao Yue of Twitter. Yao spent the majority of her career working on caching systems at Twitter. She has since created a performance team that deals with edge performance outliers often exposed by the enormous scale of Twitter. In this podcast, she discusses standing up the performance team, thoughts on instrumenting applications, and interesting performance issues (and strategies for solving them) they’ve seen at Twitter.

Why listen to this podcast:

* Performance problems can be caused by a few machines running slowly causing cascading failure
* Aggregating stats on a minute-by-minute basis can be an effective way of monitoring thousands of servers
* Being able to record second-by-second is often too expensive to centrally aggregate, but can be stored locally
* Distinguishing between request timeout and connection/network timeouts is important to prevent thundering herds
* With larger scale organisations, having dedicated performance teams helps centralise skills to solve performance problems

More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2wnBemB

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/2wnBemB

Twitter's Yao Yue on Latency, Performance Monitoring, & Caching at Scale

This week's podcast features Simon Brown well known for his work training software architects. Topics include the differences between a tech lead and an architect, how much documentation is enough and what that looks like in a continuous delivery environment.

What you'll learn on this podcast:
•	As an industry we seem to have lost our knowledge of how to do architecture well in the context of modern agile software teams.
•	Architecture is about the expensive decisions; things that are costly to change later.
•	Ideally architects should code in the production code base. If you are not able to do this at least be involved in quality reviews and peer reviews in the production code so you can get feedback on your designs.
•	It is often said the the code is the only documentation you need but the code can’t tell you everything. You do need to document the things you can’t get from the code such as the architectural drivers, they key quality attributes and so on along with some high level diagrams and how you operate the system.
•	As you step into the role of architect go and find a mentor or a local meet-up. The major change is that you have to influence and lead people.

This podcast is sponsored by AppDynamics. Software architects play a critical role in designi¬¬¬ng, executing, and migrating large infrastructures to the cloud. Download AppDynamic’s FREE eBook “10 Tips for Enterprise Cloud Migration” and launch your migration project with a proven plan. Download the eBook now at http://infoq.link/web_sndcld_appdynamics 


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/2xvq7qM

Show notes

Simon Brown on the Role of the Software Architect in a Continuous Delivery Environment

Shubha Nabar is a senior director of data science for Salesforce Einstein. Prior to working for Salesforce, she was a data scientist at LinkedIn and Microsoft.  In the podcast she discusses Salesforce Einstein and the problem space that they are trying to solve, explores the differences between enterprise and consumer for machine learning, and then talks about the Optimus Prime Scala library that they use in Salesforce.

Why listen to this podcast:
* The volume of data, and hardware advances have made it possible to do machine learning to do them a lot faster.
* AI is a science of building intelligent software, encompassing many aspects of intelligence that we tend to think of as human.
* If you can’t measure something, you can’t fix it.
* You have to think about what you can automate, rather than having a human to try and engineer out all those features.
* Get feedback on design.

Nora Jones, a senior software engineer on Netflix’ Chaos Team, talks with Wesley Reisz about what Chaos Engineering means today. She covers what it takes to build a practice, how to establish a strategy, defines cost of impact, and covers key technical considerations when leveraging chaos engineering.

Why listen to this podcast:

- Chaos engineering is a discipline where you formulate hypotheses, perform experiments, and evaluate the results afterwards.
- Injecting a bit of failure over time is going to make your system more resilient in the end.
- Start with Tier 2 or non-critical services first, and build up success stories to grow chaos further.
- As systems become more and more distributed, there becomes a higher need for chaos engineering.
- If you’re running your first experiment, get your service owners in a war room and get them to monitor the results of the test as it is running.

More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2vJoimw

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 extended shownotes? Check the landing page on InfoQ: http://bit.ly/2xK7OxR

Shubha Nabar Discusses Einstein, the Machine Learning System in Salesforce

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

InfoQ - Podcast

Charity Majors on Honeycomb.io, the Social Side of Debugging and Testing in Production

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

Apache Beam Founder Tyler Akidau Discusses Streaming System and Their Complexities

In this podcast Shane Hastie, Lead Editor for Culture & Methods, spoke to Josh Evans, former engineering manager at Netflix on how Netflix does DevOps and the freedom and responsibility culture that undermines their way of working. 

Why listen to this podcast:

•	There are many interpretations of the term DevOps, it is a useful shorthand for a wide variety of technologies and approaches 
•	“You build it, you run it” is the concrete application of the freedom and responsibility culture
•	When building a platform tool make it so easy to use that the product teams are not tempted to try and build something for themselves
•	Product teams are free to experiment and learn, which can feel chaotic and is a valuable part of the freedom and responsibility culture
•	The value of blameless and safe incident reviews – the goal is to learn and find patterns and use that information to present whole classes of failure from happening in the future
•	Don’t view the value stream in a fragmented way – see the whole end to end system with all its interactions and dependencies and optimize the system as a cohesive whole rather than different tools and domains

More on this: Quick scan our curated show notes on InfoQ http://bit.ly/2mtCIr1

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/2mtCIr1

tech

Vikas Gulati 1