Amazon web services: cloud best practices (part 2)
在 Amazon Web Services Blog 上，有一篇相當棒談論 Amazon Cloud 的技術文件：New Whitepaper: Architecting for the Cloud: Best Practices，以下為我對於 Amazon web services 對於雲端技術的概念介紹，做重點心得分享。
雲端技術加強了一些過去建置高延展性網路架構且介紹發展出新的概念，讓整個應用系統開發建置和部署的方式做了改變。當有實作寫過雲端技術這方面概念，會感覺到『怎麼每件事情都改了呀！但也不是全部拉。』雲端技術是改變了一些程序 process，模式 patterns，方式 practices，方法理論 philosophies 和加強了我們過去學到的傳統 service-oriented architectural 原理。
目的建置可延展 (Scalable) 架構
要規劃出延展性的開發架構來取得到延展性的內部硬體設施是相當不容易的。雲端雖然是設計出來概念用來提升延展性。但是如果我們的架構沒有辦法延展的話，也無法帶出內部硬體設施延展性的實力。兩者藥盒做。要定義出單獨的元件 (components) 和架構上的瓶頸 (bottlenecks)，找出架構無法提供出好效能服務的地方，為了能得到雲端技術帶來延展性的內部硬體設施好處，需要重新建構 (refactor) 應用程式。
瞭解彈性 Elasticity：
Scale-up approach，這是不用擔心投資太多強大的電腦水平擴充來符合需要，能夠成本花費的有效，而且不是一階段一階段的擴充，比較貼近量而做調整。
傳統 scale-out approach，建造架構起來，水平擴充投資。大部份的企業或是大型 web application 跟從這樣的模式來部署他們的元件，放置他們的資料，發展出服務導向 (service-oriented) 的設計。這個方式有時候會有效率，但是她還是需要去預測需要量的時候。通常會導致太多的經費開支和人工勞力費力監看。甚至變成 Slashdot Effect。
Slashdot Effect 是發生在突然使用需求湧入，但是硬體裝置卻跟不上導致服務變慢或是停擺，這樣對於投資已久造成很大的冤枉。如果低估，就會無法應付突如其來的流量，導致顧客不滿意。如果高估的話，又浪費太的金錢投資在超過的資源。
此圖為 Whitepaper 裡面的介紹圖表，X 軸為時間 Y 軸為內部基礎設施的投資，如果紅色線是使用者流量需求，不論是一般 Scale-up 或者 Traditional Scale-out approach 都一直在跟著時間成長，但是當需了某段點需求超過成長，那段就會失去客戶的需求與滿意度，造成冤枉損失。而透過自動化 Automated Elasticity 可以即時自動根據來做預期做出應變上的措施，符合流量預期與達到客戶使用上預期的服務。
根據需求且彈性 (Elastic nature) 的提升 approach，簡單的控制電腦資源多寡且用很小的摩擦影響。另外過去軟體架構師不會花時間和資源去調整硬體的使用量，使用雲端這樣的概念要改變，如果沒法用抱改變去實作引用 elasticity 於應用系統架構中，就無法得到雲端技術的完整優勢。所以設計出聰明彈性調整雲端架構，這樣內部硬體設施根據需要去運賺，這是一個藝術。
不要害怕限制：
要瞭解雲端技術都是提供非常抽象 abstract 資源，根據需要把他們組成出好的模式是很強大的。例如：雲端不提供一臺機器用多少記憶體，而是使用分散式處理機制，將資料分散在不同台機器上。如果資料庫需要大量使用，那麼有件役選擇資料類型。如果是讀取很重應用系統，就要分散式的撒到同步的 slaves 節點上。
虛擬化管理：
雲端技術改變了系統管理員變成虛擬系統管理員。系統管理員不再只是監看伺服器和安裝軟體或者處理網路裝置，雲端現在只要簡單的 click 即可。所以系統管理員要開使瞭解技術上如何去管理抽象的雲端資源。像資料庫管理師也要改變變成虛擬資料庫管理師，去調整後面資料的儲存模式。從新對於資料的使用思考。如果待過傳統企業會知道，應用程式開發人員跟網路管理人員很不熟，網路管理人員也不知道應用程式是開發出來做啥。現在雲端技術，兩種角色已經合併唯一。當面臨這樣架構改變，企業公司要去鼓勵這樣的知識學習且兩種角色可能會合併的趨勢。
以上為雲端技術帶來思維上概念上的改變，在想做出 best practices，要先做中學才能對於這份後面介紹的 Best practices 有更多領悟了。
雲端技術加強了一些過去建置高延展性網路架構且介紹發展出新的概念，讓整個應用系統開發建置和部署的方式做了改變。當有實作寫過雲端技術這方面概念，會感覺到『怎麼每件事情都改了呀！但也不是全部拉。』雲端技術是改變了一些程序 process，模式 patterns，方式 practices，方法理論 philosophies 和加強了我們過去學到的傳統 service-oriented architectural 原理。
目的建置可延展 (Scalable) 架構
要規劃出延展性的開發架構來取得到延展性的內部硬體設施是相當不容易的。雲端雖然是設計出來概念用來提升延展性。但是如果我們的架構沒有辦法延展的話，也無法帶出內部硬體設施延展性的實力。兩者藥盒做。要定義出單獨的元件 (components) 和架構上的瓶頸 (bottlenecks)，找出架構無法提供出好效能服務的地方，為了能得到雲端技術帶來延展性的內部硬體設施好處，需要重新建構 (refactor) 應用程式。
瞭解彈性 Elasticity：
Scale-up approach，這是不用擔心投資太多強大的電腦水平擴充來符合需要，能夠成本花費的有效，而且不是一階段一階段的擴充，比較貼近量而做調整。
傳統 scale-out approach，建造架構起來，水平擴充投資。大部份的企業或是大型 web application 跟從這樣的模式來部署他們的元件，放置他們的資料，發展出服務導向 (service-oriented) 的設計。這個方式有時候會有效率，但是她還是需要去預測需要量的時候。通常會導致太多的經費開支和人工勞力費力監看。甚至變成 Slashdot Effect。
Slashdot Effect 是發生在突然使用需求湧入，但是硬體裝置卻跟不上導致服務變慢或是停擺，這樣對於投資已久造成很大的冤枉。如果低估，就會無法應付突如其來的流量，導致顧客不滿意。如果高估的話，又浪費太的金錢投資在超過的資源。此圖為 Whitepaper 裡面的介紹圖表，X 軸為時間 Y 軸為內部基礎設施的投資，如果紅色線是使用者流量需求，不論是一般 Scale-up 或者 Traditional Scale-out approach 都一直在跟著時間成長，但是當需了某段點需求超過成長，那段就會失去客戶的需求與滿意度，造成冤枉損失。而透過自動化 Automated Elasticity 可以即時自動根據來做預期做出應變上的措施，符合流量預期與達到客戶使用上預期的服務。
根據需求且彈性 (Elastic nature) 的提升 approach，簡單的控制電腦資源多寡且用很小的摩擦影響。另外過去軟體架構師不會花時間和資源去調整硬體的使用量，使用雲端這樣的概念要改變，如果沒法用抱改變去實作引用 elasticity 於應用系統架構中，就無法得到雲端技術的完整優勢。所以設計出聰明彈性調整雲端架構，這樣內部硬體設施根據需要去運賺，這是一個藝術。
不要害怕限制：
要瞭解雲端技術都是提供非常抽象 abstract 資源，根據需要把他們組成出好的模式是很強大的。例如：雲端不提供一臺機器用多少記憶體，而是使用分散式處理機制，將資料分散在不同台機器上。如果資料庫需要大量使用，那麼有件役選擇資料類型。如果是讀取很重應用系統，就要分散式的撒到同步的 slaves 節點上。
虛擬化管理：
雲端技術改變了系統管理員變成虛擬系統管理員。系統管理員不再只是監看伺服器和安裝軟體或者處理網路裝置，雲端現在只要簡單的 click 即可。所以系統管理員要開使瞭解技術上如何去管理抽象的雲端資源。像資料庫管理師也要改變變成虛擬資料庫管理師，去調整後面資料的儲存模式。從新對於資料的使用思考。如果待過傳統企業會知道，應用程式開發人員跟網路管理人員很不熟，網路管理人員也不知道應用程式是開發出來做啥。現在雲端技術，兩種角色已經合併唯一。當面臨這樣架構改變，企業公司要去鼓勵這樣的知識學習且兩種角色可能會合併的趨勢。
以上為雲端技術帶來思維上概念上的改變，在想做出 best practices，要先做中學才能對於這份後面介紹的 Best practices 有更多領悟了。
Comments
Post a Comment