Artwork

Content provided by Scale Cast – A podcast about big data, distributed systems, and scalability. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Scale Cast – A podcast about big data, distributed systems, and scalability or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.
Player FM - Podcast App
Go offline with the Player FM app!

An Introduction to ZooKeeper Video

 
Share
 

Manage episode 60658691 series 60629
Content provided by Scale Cast – A podcast about big data, distributed systems, and scalability. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Scale Cast – A podcast about big data, distributed systems, and scalability or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.

In 2006 we were building distributed applications that needed a master, aka coordinator, aka controller to manage the sub processes of the applications. It was a scenario that we had encountered before and something that we saw repeated over and over again inside and outside of Yahoo!.

For example, we have an application that consists of a bunch of processes. Each process needs be aware of other processes in the system. The processes need to know how requests are partitioned among the processes. They need to be aware of configuration changes and failures. Generally an application specific central control process manages these needs, but generally these control programs are specific to applications and thus represent a recurring development cost for each distributed application. Because each control program is rewritten it doesn’t get the investment of development time to become truly robust, making it an unreliable single point of failure.

link to podcast

  continue reading

9 episodes

Artwork
iconShare
 
Manage episode 60658691 series 60629
Content provided by Scale Cast – A podcast about big data, distributed systems, and scalability. All podcast content including episodes, graphics, and podcast descriptions are uploaded and provided directly by Scale Cast – A podcast about big data, distributed systems, and scalability or their podcast platform partner. If you believe someone is using your copyrighted work without your permission, you can follow the process outlined here https://ppacc.player.fm/legal.

In 2006 we were building distributed applications that needed a master, aka coordinator, aka controller to manage the sub processes of the applications. It was a scenario that we had encountered before and something that we saw repeated over and over again inside and outside of Yahoo!.

For example, we have an application that consists of a bunch of processes. Each process needs be aware of other processes in the system. The processes need to know how requests are partitioned among the processes. They need to be aware of configuration changes and failures. Generally an application specific central control process manages these needs, but generally these control programs are specific to applications and thus represent a recurring development cost for each distributed application. Because each control program is rewritten it doesn’t get the investment of development time to become truly robust, making it an unreliable single point of failure.

link to podcast

  continue reading

9 episodes

All episodes

×
 
Loading …

Welcome to Player FM!

Player FM is scanning the web for high-quality podcasts for you to enjoy right now. It's the best podcast app and works on Android, iPhone, and the web. Signup to sync subscriptions across devices.

 

Quick Reference Guide

Listen to this show while you explore
Play