Amazon released CloudFront to public beta today. It’s a simple way to get free content publicly available to the edge of the network (closest to the recipient downloader).

From the AWS announcement:

Amazon CloudFront is a web service for content delivery. It integrates with other Amazon Web Services to give developers and businesses an easy way to distribute content to end users with low latency, high data transfer speeds, and no commitments.

Here’s how it works:

1. Upload your content files to S3.
2. Call the CloudFront API, specifying the S3 bucket.
3. Use your S3 bucket’s already created domain and filename in your website (no change here).
4. When a customer clicks a link the closest file is automatically routed.

UPDATE:
So, uhhh, what’s special here? From AWS’s description, CloudFront is simply setting a flag for your S3 bucket that means it’s to be distributed around the cloud or remain in a single location.

This should be an addition to the S3 service, not a separate service. The added step of having to let CloudFront know you want the edge network coverage is an unnecessary chore. It would be better as an attribute for the S3 bucket. This would make S3 a stronger brand, keep it clearer for those navigating AWS, and simplify the process of pushing content (1 less step).

Here’s how much it costs:

United States Edge Locations

$0.170 per GB – first 10 TB / month data transfer out
$0.120 per GB – next 40 TB / month data transfer out
$0.100 per GB – next 100 TB / month data transfer out
$0.090 per GB – data transfer out / month over 150 TB

Requests

$0.010 per 10,000 GET requests

European Edge Locations

$0.170 per GB – first 10 TB / month data transfer out
$0.120 per GB – next 40 TB / month data transfer out
$0.100 per GB – next 100 TB / month data transfer out
$0.090 per GB – data transfer out / month over 150 TB

Requests

$0.012 per 10,000 GET requests

Hong Kong Edge Locations

$0.210 per GB – first 10 TB / month data transfer out
$0.160 per GB – next 40 TB / month data transfer out
$0.140 per GB – next 100 TB / month data transfer out
$0.130 per GB – data transfer out / month over 150 TB

Requests

$0.012 per 10,000 GET requests

Japan Edge Locations

$0.220 per GB – first 10 TB / month data transfer out
$0.168 per GB – next 40 TB / month data transfer out
$0.147 per GB – next 100 TB / month data transfer out
$0.137 per GB – data transfer out / month over 150 TB

Requests

$0.013 per 10,000 GET requests

Been using Google’s Chrome browser for a day, and so far it’s a great experience.

No. Sorry. That’s an understatement. It’s revolutionary. As the comic describes (yes, Google released a comic to introduce Chrome), this browser takes the web to impossible places. It makes the web more like an operating system, allowing each site (tab) an independent process and memory allocation, improving javascript speed – via a virtual machine – by orders of magnitude, and integrating more cleanly with Gears.

I’ve liked the browser enough to find Windows more useful than OS X this morning. A strange feeling indeed.

I’d mentioned in an email yesterday that the question was whether Chrome would quickly grab users away from Internet Explorer and other browsers or if it would be incremental in its chipping. My expectation is that it will still be chipping, but it’s going to be much faster than expected.

Just as the Google search tool grew wildly popular purely out of speed and relevance, the Chrome browser will gain huge momentum because of speed and relevance. Since there are still massive amounts of IE6 installations out there (proving that not everyone goes out and upgrades) a swing won’t happen over night, but it will gain ground more quickly than Firefox or Safari (Opera not mentioned since Chrome pretty much destroys the reason for Opera’s existance – speed).

A couple questions are begged… Is this where we really see web 2.0 take hold? I think so. And how does this affect Google in terms of monopolizing the web? They now own search and could quickly dominate the browser.

The 2,000 follower limit, it would seem, was put in place to prevent mass following and spam on Twitter. This was pretty frustrating for me since I fell in to their beyond-the-limit zone (I followed over 6,000 people because I loved the information, but couldn’t add any more).

I’m not complaining too much, as I’m enjoying the more traditional use of my Twitter account for now, but this is a ridiculously short-sighted fix.

I haven’t seen much attention drawn to the following facts (pun wasn’t intended):

1. People are more likely to recipricate a follow request from someone with a low following/friend count.
2. There isn’t a legitimate way to prevent someone from having multiple Twitter accounts (accounts are tied to email addresses).
3. The Twitter API limits are based on account, not where the call is coming from (one server can make many requests on behalf of other accounts).

From the above simple observations, one can see the easy way to follow an unlimited number of people.

1. Create a large number of accounts.
2. Follow a smaller number of people with each account (you’ll have better reciprocation).
3. Follow a lot of people (the API limitations will apply per account, so your follows-per-hour will actually be quite large).

The people running Twitter are great. They’re really trying to do the right thing. So maybe I’m completely wrong when I anticipate the above and say that this looks like a Facebook move. Facebook’s 5,000 friend limit works for Facebook. Facebook’s API is advanced and robust and complicated enough to not get terribly nailed by multi-account mass spam following.

Additionally, the information load on Facebook is different. You get a clear picture of who a person is that is friending you. You’re given enough information to make a decision. On Twitter, this isn’t the case.

So what’s going to happen?

1. Spammers are already adapting to the limitation, as described above.
2. Tweeple will stop trusting low follow-count users (do you trust an eBay user without feedback?)
3. Twitter’s servers will still be inundated and over capacity.

I blame it on Scoble…

Twicecream – a fake service to demonstrate a point about single sign-on…

In web 2.0 there is a determination to screw up potentially great services. It’s my number #1 pet peeve with software development these days. Here’s a fictitious example of a service you might create…

You’ve built a service that automatically Twitters your geo-position and the name of an ice cream parlor when you’re in front of it. Your phone buzzes when an ice cream parlor is detected and begins sending photos to SnapTweet and TwitPic, including Zagats ratings and commentary. Other patrons respond back and generate conversations. This is your social network: Twicecream – a social network for twittering ice cream enthusiasts.

In front of Ben & Jerry’s on the Wharf, Zagats 4-stars, pics: http://twicecream.com/abc123

Congratulations! You just failed.

You didn’t fail by creating a service few would use. You failed because you didn’t utilize the authentication mechanism your patrons preferred. You built an unnecessary barrier to your garden by requiring an unnecessary account creation. Don’t do this, it’s arrogant and inefficient.

Your patrons have Twitter accounts. Twitter has an API. Your service should have asked the patron to log in with their Twitter credentials.

This isn’t just for social networking. This goes for all web services. SaaS solutions that require secondary account creations are a bad idea. Single sign-on, whenever possible, should be used.

The whole idea is to simplify access to what the customer needs. If you’re requiring unnecessary account creations, you’re screwing it all up.

Chris Bilson (@cbilson) had a good description regarding my post about Twitter’s scaling/architecture challenge.

“Kevin Rose and Leo Laporte tweet at the same time = crossing the streams”

I dunno if Proton Packs have exponential load challenges, but the end result for a server can feel similar. Is my post I pointed out that Twitter has to determine delivery options and potentially deliver between 100 million and 1 billion updates per day.

But that’s in a day. 1 billion messages in a day are a piece of cake when spread over 24 hours. What if 1 billion messages have to be delivered in an hour? Or all at once?

Take my list of the top-10 Twitter accounts and imagine them all at TED, WWDC, Google I/O, or your local unconference. These ten users, if each sends an update around the same time create 321,928 messages that need delivery (total number of followers for top-10 accounts). This is an awesome amount of message delivery. If those ten users live-blog or get conversational and send ten updates in an hour… 3,219,280 (again, that’s from only 10 users).

I don’t illustrate this to state it’s these power user’s fault. Absolutely the opposite. They’re generating amazing amounts of traffic, which is a wonderful thing, and the algorithms are the problem.

It’s possible to optimize algorithms and modify systems for maximum performance. I bring up Twitter’s challenges because I’m wondering if this is a challenge beyond present day computing.

To open some minds, here’s an impossibility often overlooked: Huge numbers in a deck of cards (just to show impossibilities can stem from small initial numbers).

Twitter has been having all kinds of scaling challenges. There have been hundreds, if not thousands, of posts on the subject. Dave Winer pushed an idea for a decentralized Twitter (and has since admitted the power of Twitter is in its centrality). There is a single, simple, reason for Twitter’s challenges – Math is against them.

The facility of communication on the Twitter service is absolutely outstanding. I’ve written extensively about using it to receive an amazing amount of quality information in my series on flow.

I originally questioned the scaling ability of the service prior to SXSW, but when the service held up I went back to the drawing board to make sure my numbers were correct.

Before continuing, let’s establish the basics about the service so the math will make sense…

• Each Twitter account can follow any other Twitter account (bear with me and forget those accounts with private updates).
• Messages travel in one direction, from the updater to the follower.
• Each account has updates from other accounts it follows placed in its timeline.
• A Twitter account can selectively receive pushed updates immediately via instant messenger and SMS in addition to having an update added to its timeline.
• An update added to an account’s timeline may or may not be push based (lets assume it’s demand driven, or pull based).
• An update sent to an account from an account denoted as SMS or IM announcement is push based (there is no other way to send an update – it must be actively pushed from the server).
• The mere possibility of an update needing to be pushed requires the system to check with each follower’s settings, thus requiring analysis of each follower for each update.

A warm-up equation

If there are one hundred (100) users and each user follows ten (10) fellow users, and each user sends ten (10) updates per day, assuming all updates are push-based, how many updates are sent?

The answer is 10,000 – each sent update (100 users x 10 updates) is forked out to 10 followers who have requested push updates. This is a very large number of updates to send out via SMS or IM compared to the base of users.

A very important fact: It doesn’t matter if a user follows with the intention of receiving an SMS or IM update. The possibility of an updating needing to be pushed requires Twitter to examine every follower when an update is received.

From 1999 to 2004 I worked as a software engineer at Mplayer (who then changed names to HearMe, who then sold their video technology to LIvVE, who then was bought by GameSpy).

As with any chat room, the scaling is similar to Twitter. We had to restrict rooms to 500 users (and had insanely reduced reliability as we approached 500). As shown with the warm-up, each message is forked out to every user. We capped at 500 in a chat room because each user in a room contributes some amount of messages, and therefore as users join a room the traffic grows exponentially.

Official and unofficial numbers

According to Twitter’s blog post with stats, 50% of the Twitter population has 10 followers. 10% of users have 80 or more followers. According to TechCrunch’s research there were 200,000 active users posting 3,000,000 updates per day (as of the end of April 2008). The average Twitter user posts 15 updates per day (3,000,000 divided by 200,000 = 15).

We’ll use Twitter’s percentages in their blog post and combine them with TechCrunch’s numbers. From this, we know there are 100,000 daily users with 10 followers and there are 20,000 people with 80 or more followers. To keep things simple, we’ll leave the other 80,000 daily users out of the equation for now.

• 100,000 users x 15 updates per day x 10 followers = 15,000,000
• 20,000 users x 15 updates per day x 80 followers = 24,000,000

For laughs, let’s put in the top 10 Twitter accounts with the most followers (beware, there were fights over this).

1. Kevin Rose x 15 updates per day x 46,646 followers = 699,690
2. Leo Laporte x 15 updates per day x 44,948 followers = 674,220
3. Barack Obama x 15 updates per day x 42,201 followers = 633,015
4. Alex Albrecht x 15 updates per day x 30,348 followers = 455,220
5. Jason Calacanis x 15 updates per day x 28,773 followers = 431,595
6. Robert Scoble x 15 updates per day x 28,037 followers = 420,555
7. Mars Phoenix (rover) x 15 updates per day x 26,828 followers = 402,420
8. Veronica x 15 updates per day x 26,199 followers = 392,985
9. John C. Dvorak x 15 updates per day x 24,102 followers = 361,530
10. MacRumors x 15 updates per day x 23,846 followers = 357,690

Total of average users + top 10: 43,828,920 updates delivered per day.

And that’s half of the Twitter user base, mixed with a tiny fraction of the users who have large number of followers. Realistically, my estimate above is less than 10% of actual traffic because I’ve left out the 40% and have not included the thousands of highly popular users with more than 80 followers. Additionally, the number of followers for the people in the top-10 has grown between 50 and 100 percent since the end of April! (Twitterholic)

This puts Twitter’s actual message analysis and possible delivery between 100,000,000 and 1,000,000,000 per day.

This also does not include a single page view or web service call to their servers. Those alone account for a huge amount of Twitter’s traffic.

Compared to IM traffic

Back in 2005 (ZDNet) there were 13.9 billion instant messages sent per day, with estimates of quadrupled traffic by 2009 (46.5 billion). Instant messaging is divided up among a few primary services and IMs are one-to-one. According to Wikipedia, AOL AIM has 53 million users. If Twitter became as widely used as AIM, it would grow 265 times (53,000,000 divided by 200,000).

Take our findings for the number of delivered (or analyzed) updates on Twitter and multiply by this growth and you find Twitter has to be capable of delivering between 26.5 billion and 265 billion updates (probably much closer to the latter).

How can Twitter scale?

Decentralized XMPP is probably the answer, but I don’t really know. I can see the problem though. If they grow to having one million daily users, they have between 500 million and 5 billion messages to deliver. If they grow as popular and as relied upon as AIM, they’re staring straight in to their own exponential order of magnitude.

Courtesy NASA Glenn Research Center

.

I’ve been using Twitter as a main source of news and entertainment (it’s entertaining and informative to have commentary coming in with links, events, articles, and photos). Most everything pertinent to my areas of interest are discussed, so the latest news is passed around as discussion.

As my series on flow describes, my Twitter stream is received through a GTalk client and I’m receiving about 30 to 40 tweets per minute.

This is a lot of incoming information. A lot more than one could read and keep up with all day. It’s valuable for periods of time… Jump in to the river, jump out. This is sort of like news.

Now, I love RSS. I spend a good hour per day reading feeds. I believe it will be the standard in syndication for years to come. And maybe it will be the format passed over XMPP channels, too. In using Twitter for my flow of information I have discovered how amazing real-time updates of news can be, and how HTTP (the current method of pulling RSS feeds from various servers) isn’t powerful enough.

Imagine Google Reader being push based. Instead of periodically receiving items every five, ten, or fifteen minutes. You receive new blog entries, articles, etc, within milliseconds of their publication. This becomes amazingly powerful because you are no longer reading what happened, you are participating in what is happening.

Comment systems become conversation engines. Discussions and exchanges of information become natural, rather than one-way.

HTTP and web services, with their beautiful RESTfulness, won’t be going away. They have a very effective place for on-demand pulls of data. What I’m describing is a move away from HTTP and web services which currently poll – the enablement of FriendFeed, Twitter, blogs, and news services to fire off announcements on a push basis…

Nobody wants to wait three minutes before receiving their next round of updates. We want it when it happens.