Rob Gillen在橡樹嶺國家實驗室為政府研究云計算技術。他也參加Planet技術的研究，該技術最近推出了新的云實踐，用云計算來協助政府和公營機構。他有一篇精彩的博客將云計算追溯到7年前，他在網上還有很多演講和講座。Rob也是一位Windows Azure MVP（最具價值專業人員）。

在這次采訪中，我們介紹：

基礎設施即服務的利弊
云計算的最大數據吞吐量  
云計算在計算科學中的應用  
集裝箱計算的好處  
云端架構與非云端架構的比較  
Robert Duffner: 您能介紹一下自己嗎？

Rob Gillen: 我是一名Planet Technologies解決方案架構師，在橡樹嶺國家實驗室數學與計算機科學 組工作，我的工作重心是科學和技術。

Robert: 切入主題，您認為基礎設施和平臺即服務的利與弊是什么？那些區別正在消失嗎？

Rob: 這個技術每個方面都有不同的優勢。對很多人來說，作為服務的基礎設施平臺的方法易于上手，因為你現有代碼的運行基本沒有改變。那些服務或產品大部分沒有特定操作系統的要求。

隨著我們接收更多獨特的網絡互連等專注于技術的產品 ，人們能部署越來越類似于他們非云端產品的基于云的產品。

我們已經在平臺即服務offering中看到一些有趣的東西，尤其是從低端的科學計算，在那些不是傳統的HPC用戶中，但可能他們已經在本地機器上做了很多計算并非常依賴已有的本地機器。我們已經看到一些工具被開發出來，使用平臺即服務offering本來就有的API將他們的問題和算法延伸到云端。

就區別的消失而言，我認為特定供應商只提供其中一個的日子很快就會結束。如果你看看一些供應商會發現他們有很多跨產品行為。不過，我認為在某種程度上區別將繼續存在。此外，我認為平臺即服務offering不會很快消失。

例如，亞馬遜的彈性計算云服務是名副其實的作為服務的基礎設施。然而，如果你看看他們靈活的MapReduce產品或Beanstalk產品，它們都是真正的平臺即服務。

當我們作為計算研究人員而從自己的角度比較產品時，隨著你從基礎架構產品開始，你有大量控制，它們來自于編程的角度和基礎設施的詳細信息的觀點，但是你放棄了很多傳統上與云相關的“魔力”。當你從云譜移動到平臺即服務，你放棄了一些控制，但是你獲得了很多魔力，就這種意義而言有很多事情你不用擔心。因此，鑒于你正在做的計算類型，它們對你有不同的價值。

總之，我認為個別的技術將會繼續成長，但是在供應商一級的區別將會隨著時間的推移慢慢消失。

Robert: 看上去，以目前的市場情況，作為服務的基礎設施更適合遷移現有的應用程序，并且平臺即服務則是在構建全新的基于云的應用程序類型。您是否同意這一點？

Rob: 大部分情況下是這樣的。作為服務的基礎設施肯定是比較容易遷移的，但我想修正一下你的下半句話。我認為，它取決于你想解決問題的類型。來自任意供應商的平臺即服務offering通常都很有趣，但是他們有限制，并取決于你正試圖解決的問題，那些限制你或許不能接受。

所以，我同意你的觀點，但提醒一下，不是籠統地說開發新項目的時候應當總是最開使就使用平臺即服務——你必須評估你想解決問題的平臺實用性。

Robert: 您已經與著眼于云的政府機構合作并且在貴公司推出的GovCloud 上發表博客。政府和云的其他用戶之間的關鍵區別是什么？

Rob: 最大的區別簡單地歸結為數據的隱私和數據安全。既是在政府空間的內部也是在外部，我們和每個顧客談論的第一件事是云帶來的數據安全。雖然在背后有一些好的理由，現實情況是云計算供應商通常比顧客自己提供的做得要好，特別是在私營部門。對很多那樣的客戶，遷移到云給他們帶來更好的數據安全性和數據隱私。

在政府的某些地區，有可能存在這種情況（尤其是在一些小的國家和地方政府辦事處）——云供應商實際上可擁有比他們目前正在使用的更安全的平臺。但是很多時候有政策和法律的問題，這將會阻礙他們遷移到云，即使他們想要。

我認為一些主要供應商最近已被通過基礎水平或我們稱之為低安全數據的認證，允許公共部門客戶將通常可用的數據放入云。但是按照政策非常敏感的數據還是不能被遷移，盡管實現起來還是沒有問題的。

這是今天主要考慮的一個問題，令人遺憾的是，因為事實上聯邦政府有很多任務受益于云計算的基礎設施。當我看到打破那些障礙獲得了進展時，我很高興。當然，其中的一些障礙不應該也不會消失，但是有些應該并希望它們消失。

Robert: 您寫了一系列博客帖子 關于云計算的最大吞吐量。是什么力量讓你沿著這條路走下去？有沒有這種情況，您需要將文件傳輸吞吐量最大化？

Rob: 我們認為云計算對科學問題很有價值的方面之一是對工作或超級計算機生成的數據集的后處理或后期分析。

我們選擇了大量的Jaguar上生成的氣候數據，Jaguar是橡樹嶺的一臺超級計算機，我們模擬了獲取數據并將其遷移到云以備后處理的過程。我們考慮了不同的方法，在確保數據的高度完整性的同時以更快的速度獲取數據。

我們還修復了數據發布出現的問題，以便一旦它在云里，我們可以將它格式化使得在特定研究領域內外的人都可以使用它。我們正面臨很多科學領域使用特定領域的文件格式的挑戰。例如，氣候學人經常使用類似NetCDF和HDF5等文件格式。他們使用那些有特別的原因，但是它們未必廣泛使用在其他學科。同樣的數據如果繼續保持原來的格式，想使其對更多的人可用很困難。

因此，我們正在考慮如何利用云提供的平臺基礎設施，無論他們使用的是什么數據結構，真正注冊數據服務并使其可用于新的和比以前更廣泛的受眾是可能的。

那是我們正著手解決的主要問題，并且我們發現了一些有趣的結果。與一些主要的供應商一起想出了改進數據傳輸的方法。這只有當微軟、亞馬遜公司和其他的供應商繼續改進他們的產品并使他們在科學領域更有吸引力的時候才會變得更好。

Robert: 數據中心是不透明的，在這個意義上說您對這個技術的實現沒有多大的可見性。您看到過云計算性能每天都有顯著變化的例子嗎？如果是這樣，您對應用程序開發商的指導是什么？

Rob: 就使用云的角度而言，那個問題可能是和我共事的科學家們最猶豫的事情。當面臨計算科學，我們擁有最偉大及最優秀的思想，讓他們使用這種黑盒對他們來說似乎有點可笑。

這就是為什么我不期望，至少是在短期內，看到云計算取代一些特別的調整硬件如Jaguar、Kracken或其它超級計算機。同時，有很多科學工作對執行時間的要求不是很高。通常，這些代碼不聰這些機器中可用的專用硬件中獲益。

有某些類型的模擬對時間很敏感且通信量大，意味著每執行一步計算節點間都要進行相對大量的通信。在這種情況下，一般的云平臺是不合適的。

很有趣地看到一些云供應商意識到這一事實并迎合這種風格的代碼開發平臺，有亞馬遜公司和其他公司的簇計算例子作為佐證。在這些情況下很重要，這是因為通用云基礎設施可能帶來不可接受的不一致的地方。

我們還看到很多人們發表的論文評估基礎設施即服務供應商，他們將看一看他們的計算能力一天天或一點點地急劇變化。大多數情況下，那被歸因為喧鬧的鄰居問題。當這個研究是高校學生或是其他預算被約束的人做的小規模項目時，他們傾向于使用任何云供應商提供的可用的小型或中型的實例。在這種情況下，人們在相同的盒子中爭相使用資源。實際上，取決于他們的算法和他們所選擇的配置，他們有可能在相同的物理節點上競爭，因為云供應商的資源分配算法放在相同的物理節點上。

由于科學界的人更喜歡使用最大的可用節點，他們更傾向于有保證地訪問物理機器。這將提高他們結果的一致性。取決于使用模式，他們仍共享引入變量（永久存儲、網絡等）的有利條件，但使用使用更大的節點必然會減少不一致——坦率地說，那就是更符合傳統的高性能計算集群。當你在群集中運行節點集，你對已分配的節點有完全的訪問權限。

這一領域的核心問題是對給定問題的類型確定最適用或相應的硬件平臺。如果是一個數據并行的應用程序，比起執行時間你更關心的是總有效時間或開發時間，在很多情況下云將很好地適合問題。如果你擔心滯后時間并且你有非常具體的執行時間尺度，云（至少在其目前的典型）可能不是最適合的。

Robert: 早在去年八月，您也發了關于集裝箱計算 的帖子。您在這個趨勢下看到了什么有趣的，什么情況適合它？

Rob: 該主題與我們以前談及的一個話題結合得很好，關于聯邦空間的數據隱私。很多聯邦組織正在建立大規模數據中心。為了提高效率的關鍵一點是得到任何組織、政府或其他機構來停止做無差別的繁重任務。

每個組織應該側重它的附加值，它應盡量允許其他人填補漏洞，不管是用分包、外包或其它手段。我希望將來看到更多的例子，其中數據隱私條例需要操作員，不僅是為了確保數據在某一國家的邊界內的地理位置，還為了在我的住所、公司的環境或特定的政府機構內。

你可以想象一個云供應商當中的模型，真的在你的領域內放棄數據中心的集裝箱塊，因此你有那個設備上的物理控制，即使它可能由云供應商管理。因此，一個政府機構不會制定自己的API或數據中心的設置及維護機制——供應商能提供的。客戶仍可以受益于云的內在優勢，同時維護本地硬盤上的物理控件等等。

集裝箱計算方法的另一個關鍵方面是能源效率。我們看到供應商開始將容器看作是可替換的單元，能使他們引進一些容器中沒有的設計。當你不再期望能夠換出個人服務器，你可以消除傳統服務器底盤（為了使服務器更好地減少氣流和降低功耗），你可以鞏固電源供應、體驗空氣冷卻（沼澤冷卻）、更高的環境濕度……還有更多沒有列出來，并且我們看到了一些令人印象深刻的來自不同供應商的PUE編號，我們正在努力鼓勵這些發展。

有一些有趣的模型，能夠捆綁專業的資源并在非傳統位置部署他們。例如你可以將產生器、通訊組、專門的計算資源和分析工作站，這一切都包裝在一個40尺的框中并寄給一個偏遠的研究站。

Robert: 美國國家標準技術研究所 (NIST) 最近發布了云計算報告 ，引用他們的話“沒有適當的治理，組織的計算基礎設施有可能變成雜亂、難以控制的不安全服務。”您的想法是怎樣的？

Rob: 我首先想到的是他們是正確的。

實際上，他們的這個評論類似于通常對SharePoint環境所作出的評論。任何SharePoint顧問會告訴你他們存在的最大問題是太容易得到安裝的第一個數量級，這既是該平臺的弱點也是它的強項。在一家大公司，你經常聽到有人說“我們將這些SharePoint簡單地安裝配置到我們的環境中，然而他們很難從IT的角度管理和控制。我們得不到保證來確信他們做了備份或諸如此類的事情。”

我固然贊同那種情況，但是那些簡單安裝配置解決了業務問題，并且他們存在的可能原因是一些阻礙工作完成的障礙，無論是基于政策的還是基于組織的。大部分公司只是自己設置，因為這比走官方程序要簡單很多。

類似的情況就很容易出現在云計算。當他們可以去亞馬遜公司用信用卡在短短10分鐘內就得到他們想要的，很多人甚至不會考慮經過幾個月的采購和政策及安全的確認。IT機構需要認識到圍繞那一關系需要達到一種平衡。

我認為隨著時間的推移，我們將致力于這樣的環境，有人能像去亞馬遜公司、微軟或找任何人那樣輕松地為云資源供給一個非云端平臺。這一模式還將提供一個簡單的手段來為其特定部署處理適當的安全注意事項。

我認為有價值的地方是，在想要更多管理權的IT界人和想要更大的靈活性的用戶之間有緊張的關系。對任何組織來說，想成功使用云計算，找到適當的平衡至關重要。

Robert: 您如何看待圍繞一個組織是怎樣使用云計算而不犧牲云提供的靈活性IT正在創建的管理方法？

Rob: 一些云計算供應商有使顧客事實上延伸到云的技術。如果你將那種技術與讓有組織的IT重新包裝或重新設計他們選擇的云計算供應商提供的資源調配機制結合起來，我認為你最后可以得到一個有趣的解決方案。

例如，我可以想象一個由我的IT機構管理的內部網站，在那里我可以看到可用計算資產的目錄，提供我們的內部收費代碼，并且有平臺裝設與我今天用外部供應商一樣簡單。實際上，那種情況對我來說比去外部更簡單，因為我不必使用信用卡和潛在的補償機制。在該模型中，IT組織本質上是“白色標記了”外部供應商的平臺和組織政策及流程，同時仍受益于大規模的公共云中。

Robert: 您認為什么使云端的架構不同于非云端或托管解決方案的架構？

Rob: 該問題的答案取決于你正在使用的域。我很多云計算的同事在一般的企業環境中工作，同客戶或業務，其工作目標是云的最有效位置，例如需要大量的水平刻度的應用程序。在這些環境中，它相對簡單地談論構建云與不構建云，因為線條清楚、出現固體模式。

另外，和我一起工作的很多人有至少存在十年的代碼和庫。我們仍然有人積極用Fortran 77寫程序并爭辯說它是完成這項工作的最佳工具。盡管大多數正在討論云的人會嘲笑這種說法，就是那種情況使得這個領域很獨特。

與我們一起工作的大部分研究人員不考慮構建云與否，正如他們很少考慮如何架構來解決他們特定的問題。這就是像我一樣的人們和組里的其他人一起需要做的，我們幫助生成讓該領域的科學家利用云的力量的工具，而不必一定思考或構建它。

我最近和很多人討論到云及它應該坐落于科學階段的哪個位置。十多年來，我一直在托管服務供應商的地方工作，很多年來，我一直投入做托管服務的大規模縮放，例如托管郵件（這現在被稱為“基于云的服務”）。從業務角度來看，有幾個非常有趣的方面，但是我認為托管郵件不一定可以真正捕捉云計算的本質。

在下一級別，你可以考慮大量集中的可用存儲空間或大量集中的可用虛擬機，并生成有趣的平臺。這似乎是許多人正在為云計算努力的地方，在它大量增值的同時，還可以從云計算得到更多的東西。

讓我對云構建最為興奮的是，我可以建立一個算法，能夠根據所需解決問題的動態調整環境 ，而不用建立一個算法讓它適應一個固定的環境。這是一個有趣的轉變，同時也是另一種不同的解決問題的方法。我可以為一個科學的問題創建一個算法或者解決辦法，它知道需要計算些什么,當這些需求改變的時候，它可以向外面申請獲得另外的節點、更多的存儲空間、內存等等 。這是一場游戲轉變。

Robert: 您對著眼于遷移現有的應用程序到云的組織有什么建議？

Rob: 首先，他們應該了解，這并不像聽起來那么難。其次，他們應該循序漸進的來進行這些操作。目前有多種方案和教程通過不同的模型告訴你如何實現。也許最好的方法就是用一個成熟的應用程序，考慮如何在做出最少的變化的情況下將它遷移到云。一旦他們成功的在云計算中部署好之后（或多或少沒修改），他們可以考慮一下還可以對應用程序做出什么樣的改動來更好的利用云平臺。

很多機構做出了錯誤的假設，他們認為轉移到云之后，那些應用程序就需要重新架構。這就導致他們重新架構一些關鍵的應用程序，而這些應用程序是他們業務的本質依賴。在我看來，采取大量的可控增量的步驟比采取少量的大步驟要好。

Robert: 那似乎是把它包起來的一個很好的地方。感謝您的時間。

Rob: 別客氣。