(please read here before continuing)

"look at this effing rainbow I just made for you"

Noah is an application registry inspired by Apache ZooKeeper

What does that mean? From the ZooKeeper Home Page:

ZooKeeper is a centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services. All of these kinds of services are used in some form or another by distributed applications.

Essentially Noah is a port of parts of that functionality into a stateless RESTish application.

It's probably worth reading the following blog posts before going any further to clear up any possible misunderstandings. Noah is not a direct replacement for ZK. It's a conceptual port. More than anything, it was an itch I needed to scratch:

• On Noah - Part 1
• On Noah - Part 2
• On Noah - Part 3
• On Noah - Part 4

Also the following post was where I sort of discussed it early on:

• Ad-hoc configuration and Coordination

• Paxos, ZAB or any other sort of consensus protocol
• Noah itself is not distributed (yet).
• ACLs (yet)
• Leader election of any kind

note that these terms are fairly overloaded depending on who you talk to

• Service registry
• Node registry
• Configuration Registry
• Group Services
• Watches (albeit differently)

The quickstart guide has been moved to the wiki:

Quick Start Guide

Noah has a few basic design goals:

• The system MUST support RESTful interaction for operations where REST maps properly
• The system MUST support basic concepts of hosts, services, applications and configurations
• The system MUST support horizontal scaling.

Additionally:

• The system SHOULD be flexible in deployment options.
• The system SHOULD support watches similar to ZooKeeper
• The system SHOULD support pluggable callbacks for watches.
• The system SHOULD support being a client of itself.

Noah is somewhat opinionated in its stack. Noah attempts to minimize the external requirements wherever possible to allow for the widest possible installation options. However, excellent work has been done to create performant and well-tested libraries that would be foolish to ignore. To this end, the current requirements are:

• Redis 2.0
• Sinatra
• Ohm/Ohm-Contrib
• EventMachine

The above stack provides much of the functionality needed to port over ZooKeeper concepts.

Redis is the backbone of the system. Through the native datatypes and pubsub capabilities, much of the heavy lifting has already been done.

Sinatra is the perfect library for creating API-only style applications. It allows you do focus on the meat of what an endpoint should do instead of the hassle of creating the endpoint.

Ohm is quite simply the most unobtrusive and flexible orm for Redis. It gets out of the way and allows you to very easily interact directly with Redis if the need arises

EventMachine combined with Redis pubsub forms the basis of the Watcher and callback system.

It's something I've wanted to do for a while. Everytime I've needed something like Zookeeper, Zookeeper has always been too bulky and had too many moving parts. I've also always needed to interact with it from more than just Java or C. Sometimes it's been Ruby and sometimes it's been Python.

In the end, we reinvent the wheel ANYWAY. Maybe we do something like have our CM tool write our application config files with a list of memcached hosts. Maybe we write our own logic around (shudder) RMI to do some chatty broadcasting around the network for finding local nodes of type X. We always reinvent the wheel in some way.

Here are a list of some key wiki pages:

• Concepts How Noah views various object types in the system
• API The API is currently in draft state. It will be finalized before the 1.0 release.
• Example Use Cases Some use cases for Noah and how it would fit into an existing application or infrastructure
• Watchers and Callbacks The general idea behind how Noah would implement watches
• Watcher/Callback Examples Some example callbacks.