首先讓我們瞭解一下大師們對“雲端計算”的經典看法：

    比爾.蓋茨1989 年在談論“電腦科學的過去現在與未來時”時說：“使用者只需要640K的記憶體就足夠了。”那時，所有的程式都很省很小，100MB的硬碟簡直用不完。

    李開復（現任 Google全球副總裁、中國區總裁）打了一個形象的比喻：錢莊。

    最早人們只是把錢放在枕頭底下，後來有了錢莊，很安 全，不過兌現起來比較麻煩。現在發展到銀行可以到任何一個網點取錢，甚至通過ATM，或者國外的渠道。就像用電不需要家家裝備發電機，直接從電力公司購買 一樣。

    “雲端計算”帶來的就是這樣一種變革——由谷歌、 IBM這樣的專業網路公司來搭建計算機儲存、運算中心，使用者通過一根網線藉助瀏覽器就可以很方便的訪問，把“雲”做為資料儲存以及應用服務的中心。

（一）原理：

    雲端計算（Cloud Computing）是分散式處理（Distributed Computing）、並行處理（Parallel Computing）和網格計算（Grid Computing）的發展，或者說是這些電腦科學概念的商業實現。

    雲端計算的基本原理是， 通過使計算分佈在大量的分散式計算機上，而非本地計算機或遠端伺服器中，企業資料中心的執行將更與網際網路相似。這使得企業能夠將資源切換到需要的應用上， 根據需求訪問計算機和儲存系統。

    雲端計算的藍圖已經呼之欲出： 在未來，只需要一臺筆記本或者一個手機，就可以通過網路服務來實現我們需要的一切，甚至包括超級計算這樣的任務。從這個角度而言，終端使用者才是雲端計算的真 正擁有者。

雲端計算的應用包含這樣的一種思想，把力量聯合起來，給其中的每一個成員使用。

（二）“雲”時代

目前，PC依然是我們日常工作生活中的核心工具——我們用PC處理文件、儲存資料，通過電子郵件或U盤 與他人分享資訊。如果PC硬碟壞了，我們會因為資料丟失而束手無策。

而在“雲端計算”時代，“雲”會替我們做儲存和計算的工作。“雲”就是計算機群，每一群包括了幾十萬臺、 甚至上百萬臺計算機。“雲”的好處還在於，其中的計算機可以隨時更新，保證“雲”長生不老。Google就有好幾個這樣的“雲”，其他IT巨頭，如微軟、 雅虎、亞馬遜（Amazon）也有或正在建設這樣的“雲”。

    屆時，我們只需要一臺能上網的電腦，不需關心儲存或 計算髮生在哪朵“雲”上，但一旦有需要，我們可以在任何地點用任何裝置，如電腦、手機等，快速地計算和找到這些資料。我們再也不用擔心資料丟失。

（三）雲端計算的幾大形式

1、SAAS（軟體即服務）

    這種型別的雲端計算通過瀏覽器把程式傳給成千上萬的用 戶。在使用者眼中看來，這樣會省去在伺服器和軟體授權上的開支；從供應商角度來看，這樣只需要維持一個程式就夠了，這樣能夠減少成本。 Salesforce.com是迄今為止這類服務最為出名的公司。SAAS在人力資源管理程式和ERP中比較常用。 Google Apps和Zoho Office也是類似的服務

2、實用計算（Utility Computing）

    這個主意很早就有了，但是知道最近才在 Amazon.com、Sun、IBM和其它提供儲存服務和虛擬伺服器的公司中新生。這種雲端計算是為IT行業創造虛擬的資料中心使得其能夠把記憶體、I/O 裝置、儲存和計算能力集中起來成為一個虛擬的資源池來為整個網路提供服務。

3、網路服務同SAAS關係密切，網路服務提供者們能夠提供API 讓開發者能夠開發更多基於網際網路的應用，而不是提供單機程式。

4、平臺即服務另一種SAAS，這種形式的雲端計算把開發環境作為一 種服務來提供。你可以使用中間商的裝置來開發自己的程式並通過網際網路和其伺服器傳到使用者手中。

5、MSP（管理服務提供商）

    最古老的雲端計算運用之一。這種應用更多的是面向IT 行業而不是終端使用者，常用於郵件病毒掃描、程式監控等等。

6、商業服務平臺SAAS和MSP的混合應用，該類雲端計算為使用者和 提供商之間的互動提供了一個平臺。比如使用者個人開支管理系統，能夠根據使用者的設定來管理其開支並協調其訂購的各種服務。

7、網際網路整合將網際網路上提供類似服務的公司整合起來，以便使用者能 夠更方便的比較和選擇自己的服務供應商。

二、SaaS軟體即服務五大認識誤區

誤區一：SaaS服務是一種次要的發展趨勢

    仔細觀察一下統計資料，你會發現SaaS服務正在逐 漸步入主流應用行列。專門幫助企業部署SaaS應用的諮詢公司ThinkStrategies協同IT研究分析機構Cutter Consortium，耗時四年的時間針對SaaS服務進行了統計調查，最新公佈的調查報告顯示，SaaS服務使用量已經從2007年的32%上升到 2008年的63%.

    更重要的是，超過90 ％的受訪者都表示對SaaS服務的滿意，並且計劃重新定製及擴充套件SaaS服務的產品。此外，多數受訪者表示要向同行推薦SaaS服務。SaaS服務的滿意 度和推介水平都是傳統軟體商曾經的夢想。

誤區二：SaaS服務只可以提供一種應用

    事實上，如今SaaS服務的形式和功能已經和各種各 樣的傳統軟體產品相差無幾。

    雖然可訂購的SaaS服務目的是使一個單獨的程式碼庫 可以支援多個使用者，但SaaS服務的包裝和定價方式卻多種多樣。如今，線上SaaS服務供應商已經超過950家，所提供的SaaS服務應用涉及80多個領 域。

    另外，使用者還可以配置越來越多SaaS應用，以滿足 其個人的需要。雖然SaaS服務的定製級別無法達到傳統應用程式的高度，但這不一定是壞事。不少企業按傳統級別定製內部應用程式，因此企業軟體無法完全支 持其供應商，並導致軟體不能輕鬆地升級。

企業及IT決策者們已經認識到：高水平的（軟體）定製可能會起到反作用。

誤區三：SaaS服務會過於簡化應用程式。

    毫無疑問，多數SaaS應用的成功都是因為它們的部 署、使用及維護都要比企業內部應用程式更為簡便。但是，SaaS應用的簡化並不意味著要犧牲一些使用者功能。

    相反，我們看到了企業通過應用SaaS服務而出現的 穩定增長。事實上，SaaS 服務公司Salesforce.com去年增長最快的客戶群是大型企業，通用電氣和偉創力通訊（Flextronics）都宣佈要部署各自的SaaS服務 ——Aravo的供應商資訊管理服務解決方案及Workday的人力資源管理系統。

誤區四：SaaS服務的可靠性及安全性較差

雖然谷歌和Salesforce.com提供的服務也會中斷，但這樣的事故不是經常發生，而且持續時間 也不會太長。迄今為止，並未出現因SaaS服務而導致企業重大損失的事故。

誤區五：SaaS 服務並不受IT從業人員的歡迎

雖然有些人擔心SaaS服務會危及他們的飯碗，但多數人都認為，SaaS服務是一種必然趨勢。更多的 IT從業人員已經認識到，SaaS服務不僅讓他們從日常的傳統軟體中解放出來，而且新一代基於SaaS服務的IT管理軟體能夠真正幫助他們更好地管理自己 的IT事務。

三、PaaS模式受開發人員青睞

    PaaS（平 臺服務化，Platform as a service）開發模型正在迅速贏得支持者。與傳統方式不同,在使用PaaS開發 時，開發人員使用由服務提供商提供的免費程式設計工具來開發應用，並把它們部署到雲環境中。PaaS提供商或其合作伙伴提供基礎設 施，並根據CPU使用情況或網頁觀看數等使用指標來收費。

    使用PaaS開 發，開發人員可以極具生產力。他們不必為定義可伸縮性要求而操心，也不必用XML編寫部署說明，這些工作全部由PaaS提 供商處理。

    Garrett Davis過去30多年來為大型保險公司編寫軟體，但現在他開始求助於Google App Engine在PaaS雲中完成他的工作。Davis說，使用App Engine可以很快完成以前耗時很久的開發工作。

    PaaS也 給Author Solutions公司CIO Michael Iovino留下了深刻印象。他的8名程式設計師利用Salesforce.com 公司的Force.com 平臺開發了iUniverse創作應用。只用3個月時間，就建立了一個完整的程式。

    ECM Institute公司經理Ray Chance指出PaaS的另一大誘人之處：低費用。他們利用Google App Engine定製的RSS服務將資訊傳播給自己的1000家成員。Chance說， 只要每月網頁觀看量不到500萬，並且需要不到500MB的線上儲存空間，Google就 是免費的。更重要的是，他可以將RSS應用部署在Google的資料中心並得到維護。Davis把 這個資料中心形容為“地球上最複雜的晶片和儲存的集合”。

但是PaaS開發也存在著缺點。例如，Chance說，Google App Engine存在記憶體管理的侷限，快取問題會限制RSS從他的站點提供RSS饋送的 速度。

    Iovino說，Force.com環 境相當強健。而且Salesforce.com的AppExchange第三方軟體市場提供了更多 的開發工具。但他補充說，如果PaaS模型要想長期取得成功的話，Force.com程式碼管理能力 需要進一步加強。現在，他們必須將一個長的服務呼叫或資料請求劃分為多個更小的、更可管理的部分。

    Saugatuck Technology公司分析師Mike West說，儘管研究表明，PaaS處在早期階段，但由於其投資回報，仍將吸引來自各種規模的企業的開發人員， 越來越多的應用開發資金開始湧向PaaS。