Hi Marcel, >> just dropped some thoughts on the application architecture on the >> wiki. I'd love to get your feedback on this! > > About the infrastructure layer. I mentioned this before, but I do not see why > Amdatu should even target "unmanaged" IaaS so I would myself leave out the > "bare metal" option and always assume there is some API available to talk to > a cloud (even if that cloud in the end is just one fixed machine).
I did not mean to suggest Amdatu would handle bare metal provisioning. It is just that I explicitly wanted to show that the OS could just be running on bare metal as opposed to some kind of virtualization with dynamic capabilities. I'll remove it if it makes you feel better :) > The layers you present make sense to me. What I do like about OSGi is that > you can pick the exact set of components you need, so I would de-emphasize > the need to have all the components that make up a specific layer present. > What I actually dislike about Spring, JEE and other more traditional > enterprise stacks is that they are extremely monolithic (modules that have so > many dependencies that you have to deploy them all are just as bad here) and > contain all kinds of stuff you don't really need. Agreed, I just think at this point the layering helps us thinking about dependecies and qualities. In now way should it suggest a packaging monolith. Eg. Just to frame statements like the core can not depend on a foundation service like cassandra and I put in a sentence stating that any foundation service should be inherently multi-tenant. > What I'm not quite sure about is the right most column, dealing with mostly > management. I see why you position it as a vertical, but for example, I > cannot explain why "topology management" in the service fabric layer would > not be part of that same vertical. Also, the foundation services seem to > contain a "management" component. I guess I'm struggling with the concept of services/components responsible for managing something versus the management functions of the Amdatu platform. Not sure how to resolve this, maybe I'm trying to show too much? In the end the vertical management part will probably be nothing more then a (or several) composition(s) of core, foundation, framework end application coponents right? > Logging does not make sense as a foundation service to me as it would imply > that any component below that cannot log anything True, not the core capability, low level java logging / osgi logservice as is right now. However, it could when you position it as a multi-tenant foundation service. Which to me raises the question: Are foundation services inherently multi-tenant? An are core services as well or will they always have a facade or.. hmm? I like the fact that Paul Fremantle also mentions Log in his todo list at http://pzf.fremantle.org/2010/11/building-cloud-native-software.html ;) > I do not believe that we can have a single "caching" component that can > implement all kinds of caches. First of all I think caches should always be > optional: you only deploy them if you actually need them. Secondly, I think > they heavily depend on the service they operate upon. I do think you might be > able to provide some kind of library with "popular caching algorithms" but > the actual cache implementation would mostly be very specific to the service > it caches. You may be right. I have no specific implementation in mind. Considering our fondness of REST it could be a generic incomming HTTP document cache for aggregation purposes or it could be a simple DHT style object cache of some sort. My main purpose was creating a feel for the types a services one could expect at this level. Generic in nature and there to provide (optional) building blocks to support application developers with the hard stuff (object caching in an OSGi environment for example). Thanks for the feedback. I'll post an update soon. Regards, Bram
