Friday, March 13, 2009

Amazon EC2 Reserved Instances

There have been some exciting developments recently in the world of Amazon EC2. For a long while, they've had compelling offerings for batch-oriented services and ones requiring dynamic scaling, but weren't as strong from a pricing perspective for interactive services with fairly steady demands. Well, that's no longer the case. Amazon just announced the introduction of "reserved instances" on EC2, which are different from regular ones in two primary ways. Reserved instances are guaranteed to be available when you ask to activate them and their pricing structure involves an up-front fee in return for a lower hourly operating cost. The availability guarantees are certainly an interesting development, but I'm not going to discuss those here. What currently excites me are the pricing options and what they mean for some architectures and demand patterns.

Others have already done the math comparing Amazon's reserved instance pricing with other hosting options and with standard EC2 on-demand pricing, but I've haven't seen anyone pointing out where the break-even point lies for a reserved instance versus an on-demand one. For example, a small instance costs 10 cents/hour on-demand and $325 (1 year plan) or $500 (3 year plan) and 3 cents/hour reserved. You'll only need to use a reserved instance for 4643 hours on a 1 year plan or 7143 hours on a 3 year plan before the reserved instance starts being cheaper per hour on average than an on-demand one. I've based this on the following equation: .1 * hours = upFrontCost + .03 * hours. For a 1 year plan, that works out to be 193.5 days/year, 16.1 days/month, or 53% of the time. For a 3 year plan, it's 2381 hours/year, 99.2 days/year, 8.3 days/month, or 27.2% of the time. (I'm not factoring in the time value of money here [paying $325 or $500 up-front is not the same as being able to spread it out over 1 to 3 years]. I'll leave it to the reader to do that.)

What does this all mean? If your architecture or typical demand requires 3 instances be running all the time, but you want to be able to dynamically scale up your instance usage, you can reserve the 3 consistently required instances and use on-demand ones to handle spikes in demand. In fact, it might even be worth reserving more instances even if you expect (with higher than 53% confidence), but aren't sure, you'll need them.

Update: On August 20, Amazon announced lower pricing for reserved instances.  I'd redo the math above, but Thomas Brox Røst did a particularly nice job in a post on his blog, so I'll let that do the talking.

Tuesday, March 3, 2009

Grails Demo Webinar

I just found out yesterday that Graeme Rocher, SpringSource's Head of Grails Development, will be giving a Grails demo webinar on Thursday, March 19. It will consist of building a Twitter clone using Grails. I've seen similar demos at SpringOne 2008 and JavaOne and I'd highly recommend "attending" if you're interested in seeing what Grails can do.

Saturday, October 25, 2008

JetBrains Seeder Program

JetBrains has recently started the JetBrains Seeder Program, an attempt to build a volunteer evangelism network for their products. I'm not sure I'd make a great evangelist, since my use of IntelliJ IDEA has mostly been limited to my experimentation with Groovy. I might join the program anyway, since IntelliJ is a great IDE (especially for Groovy) and I'm curious to see how the seeder program works.

Update: I decided that I'd already signed up for enough programs like this without taking full advantage of them. As a side note, I've been trying out NetBeans 6.5 for my Groovy and Grails projects and have been pleasantly surprised. I'll have a dilemma on my hands when it comes time to either renew or drop my IntelliJ license in April.

Saturday, October 4, 2008

ConcurrentLinkedHashMap as In-Memory Cache

For my work, I was looking for a thread-safe equivalent of LinkedHashMap that would work well as the basis for an in-memory cache.  I was hoping that such a class might be showing up in the JSR166y project, but 'twas not to be.  After that, I tried googling for ConcurrentLinkedHashMap (my previous search had been for "concurrent LinkedHashMap" [minus the quotes]) and stumbled upon a small project at Google Code devoted to exactly what I was looking for: ConcurrentLinkedHashMap.  I've been looking over the code.  It seems pretty good and I might be helping out with it, but I'm not an expert with concurrency and the Java Memory Model to the extent really needed.  I'm in touch with the main author, who seems very amenable to suggestions and corrections.  We'll see how it works out.