My Photo

About Me

  • I'm currently CEO of Mashery, a web services startup.

    I founded Mashery after leaving Feedster, where I was VP Business Development.

    Before Feedster, I've had a bunch of various similar jobs running companies in a wide range of dissimilar industries, from manufacturing to entertainment to online auctions. These include being president, CEO or COO of winebid.com, ColtHR, Justice Design, and The Groundlings.

    I have a BS in Electrical Engineering from MIT and an MBA from UCLA's Anderson School.

May 2009

Sun Mon Tue Wed Thu Fri Sat
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31            
Powered by TypePad

« Must be International Web Services Day today | Main | iPhones, iPod Touch, and Connectivity »

Two huge announcements from Amazon Web Services

AwslogoToday saw two huge announcements from Amazon Web Services. The vast majority of Mashery runs on AWS infrastructure, and today they announced two features we've been asking for since they launched. Both will save us a ton of money and improve the reliability of the service we provide our customers.

The first new service is what Amazon calls "Elastic IP addresses". Amazon loves the term Elastic - it is the "E" in "EC2". Everyone at Mashery calls them Static IP Addresses, but either way, we're thrilled they exist. Why is this so huge? Well, we at Mashery have dozens of EC2 server instances up at any given time. And from time to time, we need to shut down one instance and replace it with another. It's one of the great things about EC2 - we don't have "maintenance" downtime for a server; we merely shoot the old one and  activate a new one.

The problem is that with a new instance comes a new IP address. That is easily remapped if it is only called internally, from other EC2 instances, but if it's being accessed from outside of EC2, the external URL needs to be remapped to the new IP address. This is done by changing your DNS settings, and these changes take considerable time to propagate to all the millions of nameservers around the world. Until the new address has propagated, any calls coming to that URL will try to hit the old (now dead) EC2 instance.

Before Elastic IP addresses, you had two choices:

  • If you could plan the switchover in advance, you could either have both servers up and taking calls at the same time - one at the old IP, and one at the new IP - until all the nameservers were updated and the old server stopped seeing any traffic; at that point, you could shut it down. Of course, if the instance just died spontaneously, you didn't have that luxury. And like any server anywhere, sometimes EC2 instances do just die.
  • You could have a very short TTL (Time to Live) on your DNS record. The TTL tells the nameservers around the world how often to check in with your DNS to see if the address has changed. In theory, if you have a 24 hour TTL on your DNS, each nameserver (there are over 11 million nameservers in the world) that handles a call to that URL will check with your DNS if the IP address it has on file is older than 24 hours. 24 hours is fine if your IP addresses don't ever change without warning. But if you have to replace an EC2 instance handling critical traffic, you would have an "outage" of up to 24 hours until all the DNS servers reach the 24 hour expiration.

So at Mashery, we set our TTLs to 2 minutes. That way, all the nameservers (well, those that actually obey the stated TTL) would never be more than 2 minutes out of date. The problem, of course, is that our DNS has to handle calls from millions of nameservers, and a lot of them were hitting us every two minutes. We pay for DNS services from an outsourced DNS provider, and they charge by how many DNS inquiries we receive each month. It got very expensive, but we had no choice.

But with Elastic IP addresses, we can keep the same (static) IP address, and map from an old EC2 instance to a new one. The DNS does not need to be updated at all, and we can increase our TTLs. Longer TTL = fewer DNS calls = we save money.

Their second announcement is simpler to explain, though no less important. Amazon calls it "Availability Zones". We call it "multiple datacenters". Until this announcement, Amazon would randomly assign newly activated EC2 instances to a particular physical location; we had no way of knowing where it was. Now, Amazon has explicitly said they have more than one data center in Virginia, and you can specify which of your instances should be in one datacenter, and which should be in the other. Those that frequently talk to each other should be together. And now it is finally possible to ensure redundant infrastructure in more than one physical facility, so if one goes down you still have access to the other. Both performance and reliability should improve.

Plus, if you read the fine print, Amazon says that EC2 "currently" only exposes availability zones in one region (a region being a particular geographic area or country). Which means that someday (hopefully soon), they will expose more regions. So we can quickly, easily and inexpensively provide a geographically distributed service through Amazon (currently, Mashery relies on Limelight Networks for its clients who need to have our services provided from somewhere other than Virginia).

Thanks for the new features, Amazon, and bring on those new regions!

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341dfbdb53ef00e5519068df8834

Listed below are links to weblogs that reference Two huge announcements from Amazon Web Services:

Comments

So THIS is what you were talking about re: "making life easier".... gotchya! ;)

A few weeks ago it was Elastic IPs and now it's storage volumes in the cloud. The official stuff is on the AWS blog and I wrote some more about how it changes the game at http://blog.rightscale.com/2008/04/13/
The Amazon folks are on a roll!

With the addition of the storage volumes there's no doubt in my mind anymore: the cloud adopters will have much more computing horsepower and flexibility at their fingertips than those who are still racking their own machines. Cloud computing is going to be as significant for deployment as agile is for software development. You either compute in the cloud or you'll be left behind by your competitors because they can deploy faster, better, and cheaper than you can.

I'm sure you guys will want to get hold of the new storage volumes as soon as you can!

"This is done by changing your DNS settings, and these changes take considerable time to propagate to all the millions of nameservers around the world." C'mon, we all know DNS doesn't propagate. It's a client-pull not server-push technology.

Doesn't changing your TTL help in this regard? Although I'm told that the TTL is ignored by some ISPs, who set their own values.

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.