Saturday, March 14, 2009

A Teeny Tiny Bit of Fame

When I noticed I was credited for a fix on the changelog page for Tomcat 5.5.27 (search for "Passell" on the page if you don't believe me!), it made me feel a bit giddy. Does that make me a total dork? Well, I've been using Tomcat since it emerged out of the Apache JServ project many years back, so it makes me proud to think that I've helped make it better, even if just a little bit.
 
Update: my fix was incorporated into Tomcat 6.0.20 as well.

Why Twitter?

I'm not a technophobe. I don't blog as often as I mean to, but when I do, I enjoy it. I use IM on a regular basis. So, why do I have no interest in using Twitter? What do others see in it that I don't? Anybody out there reading this who can explain it to me?

Update: I have similar feelings about Google Buzz – I believe I have a good understanding of how it works, but I don't understand its value.

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.