SummaryA public response to an architecture for personal clouds posted by Johannes Ernst on this blog.
Jahannes Ernst has posted a strawman architecture for personal clouds. I posted a reply to the mailing list where he announced it, but wanted to put something here as well given that this is my archival record. Here is Johannes' architecture:
There are a few other models that we need to think about how to reconcile with your architecture. Let me enumerate three and then ask a few questions.
Respect network talks about BLT, the stack that puts business applications on top of a legal framework on top of a technology framework. The legal framework seems to correlate to your terms in some sense--the governance.
Gartner has a Personal Cloud markitecture that I can't find a public link to. It has devices at the foundation followed by Comms, Services, and Content.
The architecture that Kynetx has been using follows:
In this architecture the servers and low-level data system are all at the bottom in what I label the "kernel". On top of that is a layer of services that function like the services and libraries in a traditional OS. Running on top of the services are whatever user apps are installed in the personal cloud. This is a conception that is quite different than what many think of when they say "personal cloud." Comparing this to Johannes' makes me think we need to be more explicit about communications and governance.
I have a few questions and comments about Johannes' architecture:
Many of the things in "terms" are also "data". The intentcast (what is labeled "Personal RFP" in the diagram) for example, is a piece of data as much as a term. There will be terms against it, but it is data. Terms themselves are metadata that is structured and will be handled in the same way as other data.
I think the data the data layer is too low-level. As I point out in (1), abstract conceptions like contracts, intentcasts, etc. are data. The bottom two levels of the diagram focus on the implementation. I tried to keep that in the kernel level in my diagram. The data layer ought to, perhaps, focus more on the abstractions that people care about more than the database structures.
The management pane similarly seems focused on what a company or person *running* the personal cloud would want rather than what a person *using* the cloud would want. Maybe there's two diagrams, the user view and the operator view?
I don't think of "event network" as an application but as a communication or connectivity component.
Focusing on the server, rather than the system running on it seems backwards in the bottom level. For example, in the case of the Web, it would be more relevant to say "Apache Web server" in the computing layer rather than "Linux server." That is, computers by themselves aren't much help. It's the software substrate running on them that makes a difference and defines them. What system software is running there? I agree it's difficult to name. That in itself is telling, no?
That's all for now, but I commend Jahannes' effort in starting us talking about how we present general markitectures of personal clouds.