Windows Azure Platform 平台,其中 CDN 的部份的測試...

透過台灣微軟的幫忙,一個月前拿到了一組 Windows Azure Platform 的帳號測試,來寫一下感想好了。

在管理介面時會被提醒需要安裝 Sliverlight。沒有 Silverlight 的只能使用基本介面,同時也在登入時說明 2011 年初會把舊介面關閉:

抱歉,即使活動辦得很精彩,我還是沒興趣裝 Silverlight... 所以下面的測試都還是以基本版的測試為主。

能看的文件不多,而且要在登入後才能看 Help and Resources (這是 non-Silverlight 版本)

抓了 VSCloudServiceHelp.chm 後,打開來發現只有標題能看,每個章節都看不到內容:

實在是測不下去,收工...

分析 Y Combinator 的 Startup 所使用的服務...

在 HN (Hacker News) 上看到的分析資料 (文章是 ReadWriteWeb 的):「The Services Used By Y Combinator Startups [Infographic]」,文章裡面分析了 Y Combinator「旗下」的 startup 所使用的服務。

統計資料在「Y Combinator」這邊,另外有「Quantcast Top 100」的資料也可以看看,這邊就不提 Quantcast Top 100 的情況了。

網站主機的部份,可以看到是 Amazon Web ServicesRackspace Cloud 兩家雲端服務最大,如果把同屬於 Rackspace 下的 Slicehost 一起併進去算的話就幾乎相同了。不過自己 hosting 的部份也不少...

E-mail 服務的部份以 Google Apps 過半,接下來就是自己 hosting。畢竟 Gmail 真的太好用...

DNS hosting 的部份最大一塊是自己 hosting,而 GoDaddy 有一定的比率倒是沒什麼意外... 而 DNS registrar 的部份當然是 GoDaddy 過半 XD

接近一半的 startup 沒有 SSL,如果有的大多數也都是跟 GoDaddy 買。然後有不少人是買 Wildcard SSL Certificate...

不過還是要講,重點在於挑自己熟悉而且穩定的技術,並不是用了雲端就什麼都不用學。

Amazon Web Services 成長的一些故事...

Quora 上有人提問 Amazon 為什麼會作雲端計算,也就是「Amazon Web Services」這項服務:「How and why did Amazon get into the cloud computing business?」。

然後大魚就上鉤了,Amazon 的技術長 Werner Vogels 親自回答這個問題... 後面那段提到了本來沒有預期會有這麼大的量,而 AWS 所使用的量在公開兩個月後就超過 Amazon.com 本身,於是雲端神話就此開始...

EC2 上的 FreeBSD 8.2-RC1...

Colin Percival 前陣子公佈了 EC2 上跑 FreeBSD 9.0-CURRENT 的 ami,當時測試覺得太慢了:「在 AWS EC2 上跑 FreeBSD」,昨天他在 Twitter 上提到把 FreeBSD 8.2-RC1 也 porting 上去了

FreeBSD 8.2-RC1 is now available on EC2 as ami-d29b6abb. http://www.daemonology.net/freebsd-on-ec2/ #merrychristmas

實際測試以後發現 8.2-RC1 還是很慢,跑 portsnap fetch 要等半個小時,跑 portsnap extract 也要再等半個小時,看起來是因為 EBS 的速度太慢?如果是這樣的話就得等非 t1.micro 的版本了 (因為 t1.micro 只能用 EBS 跑)。

以目前進度來看,8.2-RELEASE 會是第一個支援 EC2 的 production 版本?

在 AWS EC2 上跑 FreeBSD

Amazon Web Services 的官方網誌上提到了 Colin PercivalFreeBSD 9-CURRENT 放到 AWS EC2 上跑:「FreeBSD on Amazon EC2」。他的網誌也提到這件事情了:「Announcing FreeBSD on EC2」,計畫的頁面在:「FreeBSD on EC2 status」。

花了幾個小時玩,發現用 t1.micro 跑 9-CURRENT 的速度真是太慢了。就算考慮到 9-CURRENT 裡面有很多 debugging code,不過這個速度實在沒辦法測什麼東西... 在乾淨的系統裡編 mtr (WITHOUT_X11=yes) 編一個小時編不完啊 XD

等 backport 回 8-STABLE 後再來玩一次看看吧...

VM Import:把 VMware Image 直接丟到 AWS EC2 上面跑...

又是一個邪惡的功能,直接把 VMwareVMDK 檔丟上 AWS EC2 上跑:「VM Import - Bring Your VMware Images to The Cloud」。

這個服務不另外收費,僅就 S3EBS 與 data transfer 的費用收費而已,不過公告裡提到目前只支援 Windows Server 2008 SP2:

You can start importing 32 and 64 bit Windows Server 2008 SP2 images right now (we support the Standard, Enterprise, and Datacenter editions).

Route 53 的幾個網頁操作介面

目前 Route 53 還沒有 AWS Console 可以用,必須自己寫 API 呼叫,或是透過比較信任的 3rd-party website 更新。

比較早出現的是 DNS 30,背後其實就是 Bucket ExplorerSDB Explorer 的公司,介面簡單而且容易懂。由於宣稱不會將 secret key 存起來,所以每次登入後都要輸入 access key 與 secret key...

另外一個是 Ylastic,這家公司前幾天也宣佈支援 Route 53 了:「AWS Route 53 DNS Management」,他們所提供的 Screenshot 看起來也還蠻簡單易懂的:

不過我不確定 Ylastic 提供的 Route 53 服務是否免費,有興趣的可以去試看看...

Amazon Web Services 的 S3 將單檔限制大小從 5GB 拉高至 5TB...

Amazon Web ServicesS3 將單檔大小從 5GB 拉高至 5TB:「Amazon S3 - Object Size Limit Now 5 TB」,這是因為先前提供了 Multipart Upload 的功能 (也就是將大檔拆成小部份後分批上傳) 才有辦法提昇限制...

雖然 split 本來就是很成熟的技術,不過把檔案單一大小拉高後總是方便不少...

Amazon Web Services 新服務:Route 53

當有多個 Data Center 的時候就應該要做的事情!Amazon 總算是出手了...

Amazon 官方的新聞稿在這:「Amazon Route 53 - The AWS Domain Name Service」,CTO Werner Vogels 的介紹在這:「Expanding the Cloud with DNS - Introducing Amazon Route 53」,產品的介紹頁在這:「Amazon Route 53」。

Route 53 是利用 Amazon 目前已經有的 Data Center (依照 CloudFront 的名單,看起來是同一組機房),加上 IPv4 Anycast 而提供的 DNS query 服務。以文件裡的範例可以看到使用了四個不同的 domain,分別是 com、net、org 以及 co.uk:

<NameServer>ns-1638.awsdns-12.co.uk</NameServer>
<NameServer>ns-144.awsdns-18.com</NameServer>
<NameServer>ns-781.awsdns-33.net</NameServer>
<NameServer>ns-1478.awsdns-56.org</NameServer>

到幾個不同的點 mtr 可以看出來有用 Anycast,只是還需要調整... 另外,依照文件看起來,暫時不提供 slave server,而必須透過提供的 API 直接改,這點是比較麻煩的地方,不知道 Console 什麼時候要提供介面...

最後來談價錢好了,每個 zone 的基本費用是 USD$1.5/month (包括 1M query/month 的量),一年也才 USD$18/year...

Route 53 之所以特別,是因為一般人就算有錢也沒辦法架出像樣的 Anycast-based DNS (這要有錢而且有量才做得到),而之前七月的時候 Cotendo 給的 quote 讓我連回信都懶得回 (雙方認知差距太大),我記得價錢好像多了好多 0...

這項服務會給自認 Anycast-based DNS 是「加值服務」而撈錢的公司一記重擊... 尤其大家都知道 Amazon Web Services 的東西出來後還是會花時間 tune,服務水準會不斷改善,比起其他公司來的穩定多了...

請支援 PubSubHubbub...

PubSubHubbub 對於內容提供者 (包括 Blog Platform 或是 Micro Blogging Platform) 已經是很簡單的協定了,不僅可以增加更新速度,還可以降低伺服器 loading,不過國內幾個平台還是沒人支援啊...

首先是標準規格書:「PubSubHubbub Core 0.3 -- Working Draft」,不過這文件對於要支援 PubSubHubbub 的 content provider 不是很重要,只要把裡面的觀念看懂就好。

PubSubHubbub 中有三種不同身份,可以用不同的伺服器跑。一個是內容提供者 (Publisher),一個是訂閱者 (Subscriber),另外一個是 Hub。內容提供者在這邊的例子就是 (Micro/) Blog Platform,而訂閱者可以是 Google Reader,Hub 則是中繼角色,目前有 Google 提供的服務可以用,也有 open source 軟體可以自己架。

第一步,內容提供者在先在 feed 中加入一個或多個 hub 位置,像是這樣:

<link rel="hub" href="http://pubsubhubbub.appspot.com" />
<link rel="hub" href="http://superfeedr.com/hubbub" />

第二步,當該 feed 有更新時送出 ping 給 hub,這部份假設用 PerlNet-PubSubHubbub-Publisher 做的話則是:

my $pub = Net::PubSubHubbub::Publisher->new(hub => 'http://pubsubhubbub.appspot.com');
$pub->publish_update('http://admin.pixnet.net/blog/feed');

就是這樣子而已!