1、開發與測試

第一組公有云應用就是開發與測試應用。在沒有采用虛擬化時，每個應用服務器和數據庫服務器都可能各自占用一臺物理服務器，也就是說，服務器的使用率只有很可憐的10%.即使采用了虛擬化，服務器也有可能未被充分利用，因為所使用的測試數據量和生產數據量相比是相形見絀的。

這些開發與測試服務器可能會用到各種人為編造的測試數據，不過這些數據可以很方便地遷移到公有云中。而且，你只有在使用到云服務時才需要付費。敏捷的開發方法論、代碼分支與連續集成，都會生成很多代碼構建和代碼版本，所有這些都要求并行地快速匯聚和釋放大量的應用和數據庫服務器。把所有這些服務器遷移到公有云上是合乎邏輯的。這不僅是說當你僅在使用到這些公有云服務時才需要付費，而且可以不必過分擔心網絡延遲、存儲費用及存儲性能等因素。

2、開發平臺服務

在組織接受DevOps原則時，它們會越來越多地用到設計、框架與原型、聚合、敏捷的項目管理、自動化的測試工具，以及開發平臺等等來進行連續的代碼集成。猶如上述，這些服務都屬于公有云，更利于程序員在需要的時候組織這些要素，在不需要的時候釋放它們。

當然，要說這些服務會把任何敏感的企業內部數據存儲在公有云上也是不太可能的。

3、培訓服務

培訓服務器一般是要在培訓開始的時候非常容易設置，然后在培訓結束時又非常容易拆卸的。而且它們有可能維護的只是人造的數據而非真實的數據。換句話說，它們天然地適合于公有云。

從控制臺上，云的預配置工具可以在數分鐘之內便可在公有云中設置或拆卸培訓服務器。這些工具還為設置自服務選項做好了準備，各類培訓組織可以自我服務。

4、一次性的大數據項目

幾年前，當《紐約時報》需要將其全部存檔轉換成PDF格式的時候，該報就使用了公有云服務。利用100臺服務器，這一工作在不到24小時之內就完成了。

因此，假如有某個大數據項目需要1萬臺服務器，需要在幾天內完成，或者在數小時內完成，那么公有云就應該是正確的選擇。任何組織都不會為了這樣一個一次性的項目而購買大量的物理服務器，即便它們可能是虛擬服務器。

5、網站

企業信息、產品圖片、價格信息、各種小冊子和其他偶然寫就但卻經常閱讀的網站和門戶很明顯也是天然地適合于公有云。不過公有云提供商的安全與隱私級別顯然要比遷移這些信息更重要。

6、客戶關系管理（CRM）

CRM軟件，如Salesforce.com是已經在云中的了，所以客戶及預期管理等工具便可在公有云中順暢地運行。通常來說，它們還未與其他內部系統（如郵件存儲，或者還有銷售與訂單管理）緊密集成，這也使得CRM系統比很多其他應用更易于遷移到公有云計算。

7、項目管理、費用報告和時間管理

和CRM一樣，這三項任務支持應用也都很適合向公有云遷移。

但是，假如你擔心銷售和財務數據的安全和私密性，則可以將這些數據分配給私有云，而將項目管理、時間管理和費用報告應用遷移到公有云中。用這種辦法，企業的關鍵數據便可在內部生成和管理，從而形成成了混合云。這么做也可以在私有云中空閑出大量的服務器用于生產或關鍵任務應用。

8、郵件

大企業多年來一直在使用基于云的郵件接收服務，并依照塞班斯-奧克斯利法案或巴塞爾II監管規則存儲舊的郵件。消費者也已經使用基于云的郵件服務很多年了。所以，企業的日常郵件如何遷移入云只是個時間問題，尤其是很多企業使用微軟Exchange服務器或Office365云服務在內部管理郵件的情況。

9、人力資源

調查一下企業所使用的關鍵任務應用和其他應用的數量，你會吃驚地發現后者的數量十分龐大，而且多數只使用一段時間，這些應用對各種關鍵的生產應用造成了擁堵。所以應盡可能多地將這些不常用的應用遷移到公有云中去，以便釋放出私有云資源用於生產目的，而且因為公有云服務是使用才付費，所以還可減少總體成本。

為此，招聘、人員安置、福利管理和其他人力資源應用都非常適合遷移到公有云中去。

10、基于云的反垃圾郵件和反病毒服務

很多組織都使用云服務來執行反垃圾郵件過濾，防病毒服務等。即便這些服務托管在組織內部，也可以很方便地遷移到組織的公有云實例中去。

最終，CEO和CFO們會希望CIO和高級IT管理者們更多地利用公有云，因為這樣做便可以把固定成本（基礎設施）放入可變成本列（即付即用服務）中。但另一方面，對安全和隱私的擔心，怕失去內部數據控制權的擔憂，也在阻礙著企業積極地轉向公有云。

幸運的是，通過嚴格地審查個別應用的性質，看它們是否能夠避開上述所有問題和擔憂。如果可以，那它們便可很輕松地遷移到公有云中，從而在私有云中節省出額外的資源，以便用于關鍵任務應用和需要處理敏感數據的其他系統。