Thanks for the feedback. I agree on splitting the administrator role in two roles: one generic sysop, and one per application (1 or more tenants). Based on that I added a third role: Marcel the Educa Administrator, and explained the various roles a little bit more.
About the multiple composites, from my point of view this is not a valid use case for Amdatu management/deployment. Just like on the generic Internet, every application should itself be prepared for unexpected updated REST APIs, services that are down, changed dependencies and other horrors. This should not be managed centrally, that is 'old' thinking from a viewpoint that everything can be controlled. Really service oriented architecture means be very service oriented; if the other party decides not to show up, do something else, want something else; adapt, not demand another contract. Graceful degradation and design for failure are common architectural design goals following this philosophy. Rolling restarts/updates/deployments; I put it in just as a check for us that this could be a very common use case, although I know this is really hard. Not only if you have only 2 nodes in a cluster and want to update one, but also when you want to update thousands of servers. For example the new twitter interface was gradually introduced in a few weeks, some users got it much earlier than others; apparently they have some kind of rolling update mechanism for that. -----Original Message----- From: amdatu-developers-bounces at amdatu.org [mailto:[email protected]] On Behalf Of Bram de Kruijff Sent: maandag 11 oktober 2010 21:10 To: amdatu-developers at amdatu.org Subject: Re: [Amdatu-developers] Use Cases Hi Martijn, > Feedback etc is welcome ofcourse. Great! My first impressions, ideas and questions: > Persona in the Use Case: > Leon is System Administrator > Dion is developer of Educa I think we will soon have to add a 'deployment role'. A developer should not be concerned with any particular install and a system administrator should not be concerned with application specific packing and deployment. I'm actually curious how ACE defines roles. > Dion has uploaded a set of OSGi bundles and other resources Dion has > finished Educa 1.1 and uploads a new distribution to the provisioning > server To elaborate on the previsou point. I think the developer 'deploys' a set of artifacts (bundles and other recources) to the maven repository / OBR. After that it is up to de packaging / deployment roles in Amdatu/ACE to define deployment packages and deploye them to any target. > Leon presses update on the first server Again, I think the sysop should be concerned with updates of the Amdatu platform itself, but the applications are the concern of the deployment role (and there could possibly be multiple persons having that role eg. per tenant)??) > Leon chooses a node, and selects the distribution 'Educa 1.0' to install on > that node. > Next to the already created Educa instance, a '+' button is shown, > Leon presses the button Leon goes back to the gadget and web based > provisioning server and presses the '-' button All these actions asume that an application is one composite which could be perfectly vaild for Educa. However I think we should consider the possibility where a complex/large application is constructed from multiple composites and one wants to partition the software topology (and thus the service topology) allowing dynamic horizontal and/or vertical scaling. > Leon presses update on the first server Leon presses update on the > second server, Hmmm diffent software versions running together.. that is always a very tricky one :) In general it may work in some cases where versions only differ on 'implementation details' but will fail in many other cases where (REST) apis change, datamodel changes or persistence model changes. We can think about schemes that may work (and maybe very labor intensive for developers), but in general I think the developer should declare how upgradeable an update is and the deployer must decide based on the information and the specific deployment topology what upgrade strategy to folow. 2 cents! Regards, Bram ________________________________________ From: amdatu-developers-bounces at amdatu.org [amdatu-developers-bounces at amdatu.org] On Behalf Of Martijn van Berkum [[email protected]] Sent: Monday, October 11, 2010 6:27 PM To: amdatu-developers at amdatu.org Subject: [Amdatu-developers] Use Cases Hi all, I rewrote parts of the Cloud Deployment Use Cases, see them here: http://www.amdatu.org/confluence/display/Amdatu/Amdatu+-+Cloud+Deployment+Use+Case Highlights of the changes: * Simplifying clustering (just press '+' or '-' to manage your cluster) * In bold the actions, the rest is context (which should clarify the 'real' steps) * Added remark sections with thoughts about architectural requirements Feedback etc is welcome ofcourse. Martijn GX | Martijn van Berkum | Directeur | Wijchenseweg 111 | 6538 SW Nijmegen | The Netherlands | T +31(0)24 - 388 82 61 | F +31(0)24 - 388 86 21 | M +31(0)6 - 15 05 08 53 | martijn.vanberkum at gxsoftware.com<mailto:martijn.vanberkum at gxsoftware.com> | www.gxsoftware.com<http://www.gxsoftware.com/> | twitter.com/GXSoftware<http://twitter.com/GXSoftware/> | twitter.com/njitram<http://twitter.com/njitram> _______________________________________________ Amdatu-developers mailing list Amdatu-developers at amdatu.org http://lists.amdatu.org/mailman/listinfo/amdatu-developers
