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: 别客气。
本文翻译自：