2009/3/31 Marco Roos <[email protected]>: > I'm not so afraid of the 'delete-all' workflow. The dykes of Holland have a >>0% chance of flooding, but I feel quite safe ;-) > > Would most harm not be limited to the local machine? That may actually plea > for cloud virtual machines: easy to setup and destroy again.
Yes, one advantage of virtual machines is that you could just throw it away after running a (I assume lengthy) workflow. The only thing left then is to limit network access, which should be possible. Off-topic: You could even start up your own business selling Taverna workflow execution as a cloud service - and run that on the cloud! Assuming EC2, they charge $0.10/hour - that's about $72/month for one node being idle. If you can sell execution of workflows for say.. $0.15/workflowrun, you'll need to sell about 480 runs a month to stay even. As most workflows don't run for a full hour, you can lower the price if the volume goes up. If workflows take longer, you can set the price for like $0.12/workflowrun as a startup cost, and $0.10 per additional hour. If you get more customers - you simply fire up another EC2 node. (One of the problems with EC2 is that they charge per hour, but you only get a virtual machine. So even if you can fire it up on demand - you have to wait for the virtual machine to start up - and also I guess you would need at least one node that can take take the response and do the on-demand startup if needed. Perhaps another business model would be to provide say cloud Tomcat's (web containers) - where you put in a .war file and pay a standing charge that is lower than $0.10/hour, and an execution charge higher than $0.10/hour. On the first request to an application, the .war is deployed, the clock starts ticking, and request is served. After some time-out (user-specified) the .war is undeployed. If "too many" requests come in, a second tomcat instance is thrown up and the .war deployed there as well. If the user has ticked that his .war can't scale to multiple containers, then the system would redistribute applications between containers, in worst case one instance per container. If the customer wants to scale more, he would have to recode his application to support multiple instances) -- Stian Soiland-Reyes, myGrid team School of Computer Science The University of Manchester ------------------------------------------------------------------------------ _______________________________________________ taverna-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/taverna-users Documentation: http://www.mygrid.org.uk/usermanual1.7/ FAQ: http://www.mygrid.org.uk/wiki/Mygrid/TavernaFaq Biological Services: http://www.mygrid.org.uk/wiki/Mygrid/BiologicalWebServices
