今天因爲要升級系統，所以在升級之前的這段時間寫寫關於雲計算的東西。
時下非常流行的一個概念，就是“雲計算了”，儼然一副大勢所趨的樣子。到了只要是做IDC的就一定要做個雲產品出來。霎時間，千雲萬雲在空中向我們飄來，真的，看上去很美。
美，肯定是顯而易見的。但是，我們真的要做好準備，否則再好看的雲也極有可能在瞬間變成烏雲一朵，甚至雷電交加。搞不好讓你的服務瞬間傾覆。
很不巧，作爲全球雲計算領導者amazon的用戶，我已經經受了兩次AWS的事故。只是時間和地點的不同。4月27日，amazon向我們證明了雲其實和我們日常的服務器一樣，也會出問題，並不是堅不可摧的。那麼剛剛這次，甚至還沒有徹底解決問題，讓我們認識到，雲不但不是堅不可摧的，而且一旦發起彪來，造成的惡劣影響範圍之大，程度之深是一般物理服務器所不能匹敵的！
“雲”到底適合什麼樣的需求或者應用？真的很難說，估計一百個人就有一百種答案。但是我們可以反過來想一想，有沒有不適合的？
通過AWS的使用來看：
如果強化單個服務器有超強的計算或者IO能力，”雲“不適合。
其實雲還是強調”夠用就好“的原則。這樣才能夠有效的利用物理的計算能力和IO能力。說到底，雲到最後體現的是一個服務的存在而不是一臺或是幾臺物理服務器。就像我們要運行一個tomcat服務，不管是那種雲，哪家的產品，無論用什麼表現形式。反正就讓你把代碼部署上去，tomcat開始服務，好一點你還可以配置一個IP搞個DNS指向。然後服務上線，別的你就不用管了。而這個tomcat提供的服務最終變成了這個雲的一個存在的服務。不用管到底在哪個服務器，那個IDC，那個國家。
”你見，或者不見它，它就在那裏，不來不去“
沒有多個節點高可用設計和實現的，小心某天從雲中直接跌落。
通過AWS出的這幾次問題，我們不難發現，一旦底層承載”雲“計算平臺的各個層面出現問題或者故障，將會影響整個在該平臺的所有服務。當然雲服務提供商需要儘可能的避免出現這樣的問題，但是一旦出現對於運行其上的公司打擊還是很大的。畢竟雲計算平臺要有足夠規模之後，才能通過更高的使用率甚至是某些複用達到高使用率、高計算能力和其服務提供商追求的商業目標（說白了就是多掙錢）。所以在軟件設計之初就要儘量滿足或者擁有云的一些特色。當然，有些大規模的並行計算估計可以不需要，反正某個或者幾個節點異常，甚至全部節點失效都沒有關係。它要的只是計算出結果而已，大不了重算，沒有7×24小時服務在線的要求。而除去這樣的需求，對於雲上運行的服務軟件的設計和最終的部署需要思考的東西還很多。例如：此次amazon在歐洲區出現的這個問題，如果可以將實例分別部署在該區的3個zone中，可以避免服務停止的故障。但是在設計之初沒有考慮多節點服務提供，部署之初考慮成本付出（帶寬等費用），則會直接造成該問題出現區域部署的服務直接全面停止。
如果有可能，應儘量早的和雲服務提供商進行較多的溝通，一般來講他們都會有專門的架構師來對我們的設計和部署提供技術幫助的。
最後，補充說下關於構建私有云的問題。
現在有的雲服務提供商，象買硬件服務器或者做項目一樣協助某些用戶構建自己的私有云。其好處可以說是成車列舉。但是需要注意的一點，雲平臺構建技術比較複雜（其複雜程度肯定遠遠大於直接管理硬件服務器），尤其一旦出現問題需要技術過硬的團隊進行處理和解決。其成本並不一定小於我們的購買物理服務器和租用IDC的成本。並且，一旦出現故障搞不好全線業務停止，而傳統的物理服務器則只是會因爲某幾臺出現問題而造成單一業務的停止，且修復速度會比較快（如果全部服務器都停止工作，基本上只有可能是地震或者你圖便宜找了一個不入流的IDC提供商）。真的別讓雲搞花了自己的眼睛。
雲肯定是好東西，但是作爲技術而言，它肯定也會有不足，也會有問題。重要的就是我們該如何去適應它，最後到如何善用它。