Re: [opensuse] Amazon AMI: openSUSE x86_64
On Friday 25 April 2008 19:03, Mark V wrote:
On Sat, Apr 26, 2008 at 12:13 AM, Randall R Schulz
wrote: On Friday 25 April 2008 00:00, Mark V wrote:
... it costs $0.12 per complete Hardy desktop ISO downloaded"
That may seem inexpensive, but one of the reasons I'm not rushing to switch my Web application deployment to EC2 is that is is not cheap. A minimal installation (which would be a little under-powered in the CPU department for my purposes) is $0.10 per unit-hour. That's $72 / month if run continuously. Realistically, I'd need the mid-range machine configuration, which costs twice as much!
Yes, an AMI approach is not ideal for all applications.
For my application, which is very heavily compute oriented, with only modest data storage and transfer demands, I'm frequently at odds with the design center of things like Web application frameworks like Grails (which I use) and deployment mechanisms like EC2 (which I don't). On the other hand, I need to support a variety of end users, most of whom would find the EC2 costs basically negligible, especially if they ran them only when they were using them. But the main advantage I see is a kind of "configure once, run everywhere" mode that I desperately need. I have many users who are not really sophisticated in installing and configuring databases and servlet containers. Providing them a modular system they could "stamp out" on their own would be ideal. But you know, just now, as I write this, I realize that perhaps a VMware Appliance is the way to go. (Do Xen or VirtualBox have a counterpart to VMware's "Appliances?"). End users can obtain either VMware server (free of charge) or one of the more fancy purchased VMware applications and run my app therein. I'm going to have to think about that option, too.
The example above is similar to my use case - 'lumpy' or periodic demand. In my scenario I need processing done in 2-3 hours, so I can fire up N (where N is some large number) of AMI's and run each one only for the time required.
For me, the model is pretty much one server per user. As I mentioned, the application is compute-intensive, so shared installations are likely to lead to excessive wait times and frustrated users.
The total time billed may will be N*2 or N*3 hours, but I'm not paying for the remaining 22-21 hours every single day. As in the above scenario demand for releases is also lumpy.
You know, if they came up with some mechanism for on-demand activation, or maybe scheduled activation (you know, "business hours" for a particular timezone or range of timezones), that might help. Actually, I don't know that they _don't_ have such a mechanism...
Overall we agree one size does not fit all. What is the break even point will likely vary by application.
Definitely. I think their design center is the kind of application that runs within an e-commerce entity such as Amazon.com. Well, one that reflects maybe a corner of Amazon.com. I worked for a subsidiary of Amazon (A9.com) for a while and used their infrastructure. They do really good software technology, and I'm frankly amazed at the scale of the operation they make work on a very reliable basis. And how they managed their growth is nothing short of miraculous. (But I will _never_ take another job where I have to carry a beeper and do on-call system maintenance duties again!!)
Cheers Mark
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
On Sat, Apr 26, 2008 at 12:21 PM, Randall R Schulz
On Friday 25 April 2008 19:03, Mark V wrote:
On Sat, Apr 26, 2008 at 12:13 AM, Randall R Schulz
wrote: The example above is similar to my use case - 'lumpy' or periodic demand. In my scenario I need processing done in 2-3 hours, so I can fire up N (where N is some large number) of AMI's and run each one only for the time required. For me, the model is pretty much one server per user. As I mentioned, the application is compute-intensive, so shared installations are likely to lead to excessive wait times and frustrated users.
I'm not aware of whether starting 20 AMI's is slower per AMI than starting only 1 or 2... might be worth digging in the AWS archives. I'm pretty sure I read one of Thorsten von Eicken's blogs describing a case when they started 500 instances - they may have stats on the delays involved. OK I just looked it up: http://blog.rightscale.com/2008/04/05/how-ec2-changes-the-game-in-batch-grid... It seems 20-35 per minute is what they settled on - I'm not certain why..... At the moment Desktop AMI's seem to take longer to start than a lean and mean 'server' instance - that is referring to Ubuntu AMI's and I'm not sure if an openSUSE AMI would neccessarily be any different? Also AWS indicate elastic-IP's can take a few minutes to fully update/propagate - these reasons seem to be independent of the AMI so an openSUSE AMI probably wouldn't make much difference there. It is also not clear how quick their persistent S3 storage snapshot will be - this should allow you to take a 'disk' snapshot (say of your data) and hand it out to each of the N-AMI's.... Again it's not clear if an AMI's configuration would impact this. Also bear in mind that this is all 'Beta'. Personally I'm hoping that these times will dive once they start moving to a full release (and Amazon stated that is their goal, esp. with the elastic-IP's) - might all be wishful thinking :)
The total time billed may will be N*2 or N*3 hours, but I'm not paying for the remaining 22-21 hours every single day. As in the above scenario demand for releases is also lumpy.
You know, if they came up with some mechanism for on-demand activation, or maybe scheduled activation (you know, "business hours" for a particular timezone or range of timezones), that might help. Actually, I don't know that they _don't_ have such a mechanism...
This out the box functionality has been frequently requested in the AWS dev. forums. There is the scalr project that might be of interest - http://code.google.com/p/scalr I don't have that need particular need so haven't delved into that project. Personally I can see the use case permutations being nearly unlimited, but perhaps over the Beta period they will uncover a some 'common-enough' use cases to justify an out the box solution, or develop a generic mechanism that is independent of the AMI. Personally I hope they manage to keep OS/software/configuration flexibility to the maximum degree possible other wise it becomes as restrictive as, in my opinion, MS (or G* ?).
Overall we agree one size does not fit all. What is the break even point will likely vary by application.
Definitely. I think their design center is the kind of application that runs within an e-commerce entity such as Amazon.com. Well, one that reflects maybe a corner of Amazon.com.
I worked for a subsidiary of Amazon (A9.com) for a while and used their infrastructure. They do really good software technology, and I'm frankly amazed at the scale of the operation they make work on a very reliable basis. And how they managed their growth is nothing short of miraculous. (But I will _never_ take another job where I have to carry a beeper and do on-call system maintenance duties again!!)
Hmm, I don't have that extensive expertise or experience.
From my perspective and location (Oz) AMi's are an improvement of several orders of magnitude in terms of cost (for example AUD 5 per GB), facilities and flexibility :)
Cheers Mark
Cheers Mark
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (2)
-
Mark V
-
Randall R Schulz