"look at this effing rainbow I just made for you"
Noah is an application registry loosely based on 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 those concepts into a stateless RESTful application.
The quickstart guide has been moved to the wiki:
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.
- 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:
The above stack provides much of the functionality needed to port over ZooKeeper concepts.
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.