AWS活用術｜AWS雲端服務像是百變組合的樂高積木

在最近這幾年，相信各位一定在媒體或廣告的強大播送下，都聽過「雲端運算」這個概念。有很多人覺得雲端運算只是換個說法，重新包裝的行銷名詞。也可能有人覺得雲端運算太神了，然後言必稱雲端。

其實雲端運算確實不是什麼新觀念，但是這幾年寬頻網路的覆蓋率、穩定性以及容易取得，再加上行動上網裝置的普及，都幫助了雲端運算概念的實現。雖然雲端運算所使用的技術並沒有什麼稀奇的，不過，如果我們想確實運用雲端運算的優勢，還是有很多根本的心態要改變。

我認為，在雲端運算這個概念裡，我們首先要學習的是，從軟體架構重新出發， 去塑造新的、適合雲端運算實際作法的系統。

過去的軟體架構，或多或少都存在著一些對於將來程式要運作的環境的假設，例如：可靠的區域網路、可靠的電力、儲存、備援系統。但是在雲端運算裡，這些假設都很可能是不存在的。通常我們有的，只是不可靠的網際網路，或不在同一個機架的區域網路、不可靠的儲存裝置、虛擬機器。所以系統如果要能適應雲端運算的操作方式，就不能以過去硬體的思維作假設。而必需以不依賴硬體的軟體架構，來重新設計軟體系統。

目前傳統系統仍然占大多數，我們不可能在短時間內一下子全部搬到雲端運算上面。這不太實際，而且風險也很大。最重要的原因就是，並不是所有系統都適合雲端運算。我們必需先對雲端運算有實際操作經驗，比較知道雲端運算服務的性質之後，才能對我們熟悉的系統評估，是否某部份適合搬到雲端運算。

在學習雲端運算的過程中，有一些比較簡單的應用或需求，獨立性比較高，可以先試著運用到雲端運算上。這樣做風險比較小，而且也可以為以後擴大使用雲端運算做計畫。

Amazon推出的AWS（Amazon Web Services）在雲端運算的服務提供者裡，一直是提供最多服務，功能眾多的廠商。這許多服務能夠給我們足夠的基礎，設計出符合我們需要的系統特性。這些特性可能是：省錢、高可用性、高性能、高彈性、高資料耐久性或是容易擴充。這些特性通常無法同時兼顧，所以我們更應該知道我們的系統需要什麼，並依此作設計與計畫。 這裡的彈性（elasticity），指的是能很快速的改變服務容量（capacity）的大小。

AWS簡史

AWS提供了完整、高可用性、高延展性的基礎建設服務（， Infrastructure as a Service），可以用來實作各種網路服務，減少維護及管理成本，而且比自己建制這些基礎建設更有彈性。在2002年時，Amazon為了方便與供應商、第三方開發商的整合，開始提供API。在2006年，第一個服務S3，一個檔案儲存服務，正式對外公開。幾個月後，EC2，一個提供虛擬機器的運算能力的服務，也對外服務了。這兩個服務就這樣，從很簡陋幾乎沒什麼其它功能，一直成長到現在連大站都在使用的服務。這當然和Amazon董事長兼執行長Jeff Bezos常講的：「提供最好的客戶服務」有關。

在這裡的「客戶」，就是開發者、管理者。所以Amazon常常會問我們這些開發者，覺得S3、EC2有什麼不足的地方。當然，每個企業都說，我們最重視客戶的感受。所以，真正做得到，才是厲害的地方。AWS以一個穩定的、快速的步調，一直更新服務內容，希望讓開發人員、管理員、或是老闆都更滿足。尤其是大家常常抱怨的地方，AWS常常很神奇地，沒多久就做出來了。這在這麼龐大的系統和組織裡，要做到這樣的程度，實在是有其獨到之處。

另外，因為Amazon的網站及系統，本身也使用AWS服務，你可以相信AWS是站在開發者這邊的。甚至可以說，AWS可能比你還擔心服務出問題或資料安全有沒有漏洞。從另一個面向來看，從實際操作上發現且所解決的問題，還有實務經驗，不是簡單的請一堆天才工程師就能搞定的。通常都是真正碰到了，才能一個一個去解決。這些珍貴的資產，都是靠長年的實際經驗的累積，才能達到的。

目前AWS已經有超過30種服務，而且仍然持續不斷地更新服務內容、提供更多的服務或是降價。 所以最新的資料，一定要常常上AWS的網站aws.amazon.com，或是AWS的部落格aws.typepad.com看看才準。

隨著AWS勢力的壯大，目前已經是雲端運算的第一品牌。AWS也把目前主要為IaaS的產品線，漸漸地向PaaS及SaaS延伸。除了提供原有客戶更好的服務之外，當然也是希望能把更多客戶拉進來。

AWS像樂高積木能任意組合

AWS的服務，是一種組合的概念，可以看成樂高積木。如果你只需要一種積木 （服務），那就只需要一直拿那種積木，堆上去就可以了（更多運算資源）。如果不需要那麼多積木，就可以還回去給AWS。而且，在你需要的時候，可以馬上拿積木過來用。最重要的是，看起來有拿不完的積木，所以不用一開始就準備好所需要的最大資源，在要用到的時到再租用就可以了。

雖然大多數的AWS的服務，都可以獨立使用。但是AWS為了提倡自己家的服務，當然會希望你用越多服務越好。以樂高積木的例子，就是使用多種積木，組合成一個作品。所以每個服務間，都有不同程度的互助合作，讓你能簡單的利用AWS的服務，就把一個系統組織起來。例如：EC2的AMI（映象檔）可以儲存在S3或EBS上，或是CloudWatch可以透過SNS發送事件的通知。

前面提到AWS的服務更新速度非常快，而且常常是依使用者回饋，決定優先順序。我舉兩個例子，是前一陣子AWS提供的服務更新，都是常常有人問我的功能。第一個例子：如何得知自己目前已經花了多少錢?

以前只能在自己的AWS帳號的「Account Activity」頁面，才能看到。但是看這個網頁很不方便，而且必需要有AWS帳號及密碼。如果是有像其它的服務一樣，有API可以去讀取資料就好了。雖然這個更新，只是把每天的使用量，以CSV檔案的格式存在S3上。但是至少比較可以用程式來處理，不用試著寫程式去分析AWS帳號的網頁。

另一個例子，AWS的CDN服務：CloudFront。目前在全球有30個邊緣伺服器（edge server），提供高速內容下載。但是在之前，CloudFront是不使用查詢字串（query string）來識別內容。也就是如果我本來的服務內容，有使用查詢字串，那是很難利用CloudFront的服務。其實動態網頁很常使用查詢字串，大多數的動態內容都需要用到它，這個缺點當然讓人不想用CloudFront。

現在你可以設定讓CloudFront使用查詢字串，去識別內容。所以既有的使用查詢字串的動態網站，可以開始使用CloudFront加快使用者的下載速度。或是，最常見的，利用更新查詢字串，強迫使用者更新一個檔案，例如小圖或JavaScript檔。在以前，一定要把檔名改掉才行。很多地方都看得出來AWS對使用者的重視。

這系列文章是希望以介紹AWS的基本服務，讓使用者能開始思考，雲端運算是否能為自己的系統帶來任何優勢。在經過這些很常見的使用情境之後，也許這也足夠讓使用者了解，雲端運算並不適合他的系統。或是能激發出更多想像，把傳統系統無法做到的高彈性，或是其它以前從來沒想過的事，一一把它實踐出來。

《作者簡介》

林允溥

《AWS雲端企業實戰聖經》一書的作者，也是資深軟體工程師，曾任職於美商Sosauce軟體公司，參與社群網站及3D遊戲網站的開發。從2006年Amazon Web Services推出 後，就開始運用AWS服務來建置網站，因而熟知AWS各種優勢、缺點、使用策略與問題解決方法。

相關報導請參考「Amazon雲端服務活用術」