Amazon EC2 and RedHat Enterprise!
Huh. Just read about Redhat and Amazon teaming up to give you RHEL Cloud Computing (via). Basically, you can now buy RHEL support with preconfigured AMI’s on Amazon EC2 directly from Amazon. And by you and now I mean you if you’re a participant in the private beta and if you aren’t now means, not now, but still.
I think it’s a pretty interesting move for RedHat and Amazon, I honestly have no idea how big an event this is (I suspect it doesn’t do too much, but who knows? People have been looking for good grid serving for awhile now) but I think it’s an interesting step forward for both of them. Redhat’s pricing of RHEL has been nutty. Seriously, it is quite expensive with not too much benefit over going with another distribution.
And it’s quite an interesting model for Amazon. The pricing of this RHEL combines a $19 monthly fixed fee per instance (regardless of instance size) and the cost per instance hour also goes up, over doubling for the small instance but only 33% and 18% for the medium and large size - clearly they’re pushing for bigger. Strangely they also taked on an extra penny for data transfer costs. I wonder if Amazon gets a slice of this larger cost or if the difference between plain EC2 and RHEL EC2 all goes to RedHat, I suspect it does not. This is really pretty cool as it sort of sets the stage for Amazon to host and supply a variety of services and AMI’s on top of EC2 - showing the flexibility and versatility of the service.
For my money, they need to make S3 more seamless for EC2 servers, build some driver that lets you mount an S3 account right onto the server so all your existing tools work. Even so, it’s a really great service and I’m curious to see how this Cloud Computing initiative works out for RedHat and even more interested to see what happens next with EC2.
November 7th, 2007 at 10:56 pm
Red Hat’s prices nutty? Mebbe so. I just blogged about this very issue.
How Much Does Free Cost?
November 8th, 2007 at 8:47 am
Nice piece! It certainly clarifies things - I honestly hate the RHEL client website. It’s incredibly confusing about what you need to get and what the various options are. Ah well. Now work out how much cloud computing RHEL will cost yearly. :)
November 8th, 2007 at 1:06 pm
How is RHEL’s pricing “nutty?” For less than a buck a day for the entry level offering, you get the OS, updates, free upgrades when new versions come out, and unlimited technical support via the web interface. If you look at other commercial Linux offerings, you will pay for upgrades and per-incident costs for support. I’d say that RHEL is pretty darned reasonable.
November 8th, 2007 at 2:46 pm
Fred, you’re right - to an extent. The problem, to the extent that it is a problem, is that you are paying a subscription fee per seat. So, if as a small or medium sized organization you are running several servers and want to keep things standardized you are paying per seat which can amount to thousands per year, even for servers that are performing minor tasks for you. For the most part, this is OS/updates/upgrades - many do not need the unlimited support - so for those people, when cheaper (non-subscription) alternatives exist it is harder to rationalize the fee.
If, as an organization you are using the support to a reasonable degree it becomes much more palatable to pay that yearly fee.
January 15th, 2008 at 12:07 am
You can mount an S3-backed file system using PersistentFS, http://www.PersistentFS.com
January 15th, 2008 at 8:42 am
Alan, huh! Thanks for the pointer looks like a really interesting product! I’m a little leery of the pricing model - I don’t love the subscription cost for something that seems more like software than service. But still, it seems like the best and only game in that town. The release notes are interesting and it seems like a really well featured product, be curious to see it when it reaches release time.
January 15th, 2008 at 12:57 pm
> I don’t love the subscription cost for something that seems more like software than service
Software Development Business Model A
———————————————–
- Ship buggy, hard-to-use software
- Make on-going revenue with an endless cycle of buggy updates, “software maintenance” and “support”
Software Development Business Model B
———————————————–
- Ship bug-free, easy-to-use software
- Make on-going revenue by “renting” or “leasing” the use of the trouble-free software
Questions:
————
Is bug-free software worth less than buggy software?
Which would you rather pay for?
Should the developers of buggy software be rewarded with on-going revenue, while the developers of bug-free software receive a one-time payment and that is it?
January 15th, 2008 at 1:50 pm
Alan, hey, I think I inadvertently touched a nerve, I didn’t mean to. I wasn’t saying that it was a terrible idea, it just struck me as odd. Of course, I think much of the world would take exception to your views of the Software Development Business Model. Beyond which, you guarantee that your software will be 100% bug free from the moment you start charging? That seems a little… like asking for trouble.
I use much software that is paid for that is not filled with bugs. Those developers are rewarded by my continuing to pay them for upgrades as they improve their product. Now, it may be the case that with a product like a file system that perhaps there isn’t a significant upgrade path - which would have a different ongoing profit model.
I don’t know, but ultimately I think your final question is unfair given that I believe and have personally experienced more than those two software models.
Saying all that for positive or negative, does not take away from the fact that I think it could be an essential piece of software for many people rolling out on EC2 and the ongoing cost negligible in the context of a successful site.
I had heard that one problem with S3 was that it didn’t have mtimes? Does this accommodate that in any way so you can see last change times and the like? (or was that lack in S3 a myth?) Am also curious about performance… I had always assumed that if such a product came around, it would be useful for certain things but not a good idea to host the files the webserver was accessing. Do you have guidelines on usage?
January 15th, 2008 at 3:55 pm
Not “a nerve”, just a POV.
S3 is not a POSIX file system and doesn’t support mtimes or any other POSIX concept. Developers have found various ways to map POSIX operations to S3. PersistentFS is basically a complete POSIX-compliant file system (like ext3 and other unix file systems) that uses S3 as it backing store. For more information, see
http://developer.amazonwebservices.com/connect/thread.jspa?messageID=74073#74073
The speed of reads is very good, primarily due to the large cache. Burst writes are very fast because PersistentFS has a short-term write back cache. With prolonged writes, PersistentFS will begin to throttle writes to prevent too much unflushed data from building up in its cache. If you want to see this in operation, PersistentFS has a number of “TraceXXX” parameters that allow you to monitor what it is doing. See
http://www.PersistentFS.com/documentation/Parameters
Storing web server files, or any other application or user data that you want around long term is a very good use of PersistentFS. I would not use it for software packages or temporary files. It could be used for log files, etc. if it is important not to lose them.
January 15th, 2008 at 4:35 pm
Alan, that thread you pointed to is really good. I hadn’t realized, although probably should have, that you are running a local cache - in my brain I now have it working along the lines of a simplified AFS.
Keeping a document root under this fs is a real boon… I presume that you could actually mount this (read-only perhaps?) on several instances? That would be really nice, too.
January 15th, 2008 at 9:55 pm
Yes, it is mountable read/write on only one instance at a time, but should be mountable read-only on as many instances as you want. Also, if mounted read/write on a single instance, it should be shareable with other instances using a network protocol such as NFS. Neither of these have been tested yet though! ;-)