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

InfoQ Podcast

Show Notes

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

Today on the InfoQ Podcast, Wes Reisz talks with two of the engineers currently working on removing the dependency of ZooKeeper in Kafka. ZooKeeper is used to maintain the metadata store required to operate Kafka. While ZooKeepers removal from Kafka will simplify the operational complexity and improve some of the scalability aspects of the platform, it is a huge undertaking that represents major changes to the overall architecture. Justin Gustafson and Colin McCabe are two engineers working on change. On the podcast, the three discuss why the team made this decision, what the ramifications are, and explore what both the near and future state will be with upgrading and operating Kafka.

Listen to the podcast for more.

Curated transcript and more information on the https://bit.ly/2H5w3hN
Follow us on Facebook, Twitter, LinkedIn, Youtube: @InfoQ 
Follow us on Instagram: @infoqdotcom

Stay informed on emerging trends, peer-validated early adoption of technologies, and architectural best practices. Subscribe to The Software Architects’ Newsletter: www.infoq.com/software-architects-newsletter/

Transcript

KIP-500: Removing the Dependency of Zookeeper on Kafka

Software engineers, architects and team leads have found inspiration to drive change and innovation in their team by listening to the weekly InfoQ Podcast. They have received essential information that helped them validate their software development map. We have achieved that by interviewing some of the top CTOs, engineers and technology directors from companies like Uber, Netflix and more. Over 1,200,000 downloads in the last 3 years.

KIP-500: Removing the Dependency of Zookeeper on Kafka

InfoQ

Related tracks