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