cliveb / choconode

Choconode: think peanut clusters. 1 node=1 peanut. network chocolate. yum
1 stars 0 forks source link

Design Concept #1

Open thoward opened 10 years ago

thoward commented 10 years ago

Something like this:

peanut-clusters-plated1-1024x768

Note the tight integration of nodes within a closed system, but the ability to partition based on workload. Also notice the clean separation of concerns; transparent base infrastructure is more of an implementation detail to deliver the value of the clusters, rather than an essential part of the cluster itself.

cliveb commented 10 years ago

Chocolate peanut cluster is a great pseudomorphic metaphor. I've been thinking about tight integration of nodes and separation of concerns after learning about Akka's message passing. Do you think it's possible to assemble two (or more) nodes back-to-back as self intermediating applications?

The apps are messengers with data and application. So each peanut cluster abstracts itself a little differently as needed. Force.com is an NoSQL Oracle database-on-a SQL Oracle database producing a highly useful but rate governed PaaS that cannot scale without IT provisioning more hardware. I'd like to see more of a portmanteau Akka + PaaS where new nodes can join the cluster and scale up-and-down on demand. Perhaps the apps are available in the users browser as well as in the cluster with each other. Adron's Masterless, Distributed Cluster of Nodes addresses the base infrastructure. masterless cluster 2 -s

Adron commented 10 years ago

+1 all the things!

ChrisRus commented 10 years ago

Howdy. Clive sent me a link to this discussion and I find it quite interesting. I'm working on a library called Object Namespace Manager (ONMjs) that's intended to be used as a building block for building out generic systems such as those you're discussing here. In a little more detail, ONMjs is a data-model-driven object factory + generic infrastructure based on observer and visitor design patterns for building dynamically reconfigurable apps and services in JavaScript (HTML 5 client/node.js are the specific target endpoints I have in mind currently).

Here's a high-level block diagram of a single server/client pair that may interest you folks:

onmjs-stack

ChrisRus commented 10 years ago

The basic idea above is that the endpoints each execute a generic instance of ONMjs that provides an in-memory object store (populated by ONMjs' generic object factory). The structure and topology of the objects is governed by a "data model declaration" which is effectively a JSON string (i.e. you pass data models around as you would any other JSON-encoded data). Actual data instances can be serialized/deserialized to JSON, and all data is URI addressable. Application logic is implemented as decoupled observer routines that react to changes in the data, leveraging introspection of the backing data model to disambiguate specific semantics at run-time. This allows observers to be written generically (i.e. they're data model agnostic). I can imagine scenarios where the data model declarations themselves are synthesized by application logic effectively closing the loop. Food for thought.

[cb -- ONMjs possibly a JSON Thermistor? http://en.wikipedia.org/wiki/Thermistor]

Adron commented 10 years ago

Can you ONMjs ONMjs when data eating?

[cb -- PaaS to PaaS integration apparently is @salesforce1's technical break-breakthru behind the #df13 marketing. I suspect using Scala / Akka for message passing between distributed paas systems. In a cluster solving Nodejs to Nodejs when data eating?]

ChrisRus commented 10 years ago

Can you ONMjs ONMjs when data eating?

If I understand the shorthand correctly then I think yes but need 'data eating' explained more to be sure.

cliveb commented 10 years ago

Pico's echo back to Troy's and Adron's cluster http://shar.es/OWSi6

picos

http://www.flickr.com/photos/windley/10142878766/