虚拟专家座谈会：迈向云开发

开发者正在不断体验多种不同的云环境。当在云中工作时，开发者应如何改变他们的思考方式？是否有某些云环境更适合于刚准备入门的开发者？而那些目前尚未涉及云开发的开发者们又如何在此领域获得相应技能呢？

为了回答这些问题，InfoQ 就云开发的现状、推荐工具和反面模式与三位意见领袖进行了交流。我们的专家组成员是：

• Adron Hall ，通晓多种语言的码农和开发人员布道师。
• Magnus Mårtensson ，微软 MVP，担任瑞典 Active Solution 顾问公司的云架构师。
• Andy Piper ，热衷于推动 Cloud Foundry 的开发人员。

InfoQ：是不是一位云开发人员的工具箱相比于普通开发者会有很大不同？如果是这样的话，那么在你们看来，云开发者更依赖于哪些传统的 web开发者不会使用的工具呢？

Hall：首先我会定义当听到“云开发人员”这个词时会想到什么。一名云开发人员就是负责这样的代码解决方案的人，解决方案是基于水平扩展的、分布式的、幂等的和异步处理，同时具有可伸缩、高度可用和弹性存储的特点。

我说在回答这个问题时当然应完全根据这个定义。一名普通的开发人员经常是在某个传统的 RDBMS 数据库的基础之上构建应用，在此过程中他会使用某个框架或是其它基于此框架之上的工具，并受到垂直扩展的限制。这并不是不好的开发方式，但是对于云或其它任何可水平扩展的环境来说，以这种方式来构建应用或服务效率会非常低。一旦达到最大物理扩展极限，开发者就完全无能为力了，因为他再也没有办法使用任何合理的方式来提升性能。

一位云开发人员会横跨广阔的资源范围来构建应用，他经常将某个应用的功能拆分成更为具体的服务或模块。云开发人员也常需要涉足于某些含有更多语言的工具包，这些语言包括从 JavaScript 到 C#、Ruby 或其它语言等。这样做的原因固然经常是出于必要，但在很大程度上也是为了在每个特定工作最适合使用的工具之间提供匹配。

所以，简而言之，云开发人员的工具绝对是不同的。

Mårtensson：云开发人员需要用很多与非云开发环境不同的思考方法来武装自己。较之于其他寄宿（host）选项而言，当处于云部署平台时，你可以很容易地获取到很多东西。良好的云平台会提供一个工具集，这个工具集与你可能使用过的相比显得非常不同。它可拥有“无限的”存储空间，该空间同时具有自动备份、内建的缓存功能、强有力的服务总线和其他特性。

公平来说，你完全没有必要仅为了获得此工具箱而去 100% 买入云计算。如果需要的话，你完全可以只是使用来自云平台的如服务总线这样的某一项服务。与任何非云环境的寄宿类型不同的是，工具箱中拥有更多 “工具”，比如快速弹性、内建容错、故障转移，以及你可以在任何时候按需优化费用的完全可度量的服务等。这些云特点常被引为 NIST 云计算定义。我认为，云开发人员有非常多的工具待去了解和运用。合适地运用这些工具可以助你构建那些以前看起来近乎不可能的、或者即使可能但也是代价昂贵的解决方案。如果这些特性被滥用的话，那么云开发人员则会冒着失去获得强大力量的希望的风险，甚至于冒着构建了更为昂贵的解决方案的风险。因为能力越强大，责任也越多。

最后，如果我们再多谈论点传统开发人员工具，其实对于云开发人员和其他类型的开发人员来说，这些工具都是极其一致的。按照我的经验，虽然在 Windows Azure 平台上使用 PowerShell 可以在云环境中获得很多收益，并且也自动化了构建和部署。但对于大多数其他寄宿情形来说，这种做法也可以获得同样的效果。我只是觉得在一个像云这样的内在的分布式环境中这样做是很自然的。对于任何一个想使用云来让自己能力更强大的开发人员，我的建议是去学习和了解云计算的真正力量。它们是你的新工具，将会助力你实现从一名传统开发者成为云开发人员的目标，你曾经为此有过一段痛苦的时光甚至于以前这只能是一种奢望！

Piper：好问题，这也是我一直仔细考虑的问题之一。Adron 在一件事上绝对正确，就是云带来的是规模——无论是就数据本身而言（同时到达的数据量，或存储的数据量）还是就你如何在云环境中为了获得可用性而扩展你的应用至跨地理位置的多个实例而言。也就是说，虽然很多专为这个新时代而创建的工具和技术（如 Riak 和其他的分布式数据库）纷纷出现，并且与以前比工具箱中出现了很多不同的工具，我总是倾向于认为，开发者使用新的云平台的最重要的一件事，就是忘掉他们过去的假设——换种方式来思考如何部署应用。

给开发人员提供一致的体验是构建能支持云应用的操作系统的目标之一。我们宁愿如此简单：用 Ruby 或 node.js 或随便某个工具来编写一个简单 web 应用，然后本地运行，或者运行在自己的单一服务器上，亦或运行在一个可缩放的弹性的云环境中。所以我们构建一个抽象层来隐藏不同的云基础设施（AWS、OpenStack 或无论什么）之间的差异，让开发人员能够很轻松地部署应用。这确实意味着他们需要意识到不能依赖于自己应用的位置、硬编码的 IP 地址或其他配置，这些都是不好的做法，而应是在编码时应尽可能将代码与数据库（它们有可能会改变）之间解耦。所以思考方式和架构都是不同的，不过最起码很多工具和代码都可以保持不变。

InfoQ**：你们认为哪些 IDE最适合于云开发？开发者应为些 IDE添加哪些东西来增强其云开发的能力？你们对基于云的 IDE**有兴趣吗？

Piper：很个人的说我是有潜在偏见的（作为一个 Eclipse 提交者），我很喜欢 Eclipse，也是 IntelliJ 和 RubyMine 的粉丝。现在大部分成熟的 IDE 都拥有非常好的插件与云服务进行交互，比如有低级别的 AWS Explorer，也有提供了平滑的构建 / 测试 / 部署体验 Eclipse 的 Cloud Foundty 集成插件。

我曾使用过像 Eclipse Orin 和 Cloud9 这样的基于云的 IDE 和编辑器，它们都非常方便。我很高兴地看到它们演进得也很快，从而可以利用最新的 web 特性。

当然很可能具有讽刺意味的是，我自己的开发者工具集根本不是以 IDE 为中心的。我将一天的大部分时间都花在 Sublime Text 以及命令行上，并且我也是 Ubuntu 的包管理和 OS X 的自制软件开源包管理器的大粉丝 :-)。

Mårtensson：听到 Andy 这么说很有趣，因为我有类似的背景，不过刚好相反。我是一个 Microsoft/C#/Windows Azure 的开发人员，这使得我在面对 IDE 环境和开发体验上极具偏见。最近 Microsoft 在 Visual Studio 中实现无缝的云开发体验上投入的努力是无与伦比的，而这是我在 Visual Studio 身上前所未见。它们确实做出了巨大的努力来支持快速和强有力的云开发。Visual Studio 中的 Server Explorer 能够踏足任何云账户并和运行其上的任何服务进行交互。你可以管理它们，监控它们，并可以在云上运行类似于 IntelliTrace 和性能监视器这样的工具。然后你可以下载结果并在 Visual Studio 中进行分析。很自然地，你能在本地构建和测试任何云应用，包括最近加入的非超级管理员模式的计算模拟器（Express 版本）。随后你可以将应用作为一个单元推送到位于 Windows Azure 上的自己的网站和云服务中。我在 Visual Studio IDE 所见到的用于云开发的（读作：Windows Azure 开发）部分在 Visual Studio 历史上是无与伦比的。干了这杯 Kool-Aid？是啊！大口地享受它吧！

Hall：很明显有至上之选：Cloud9IDE。

虽然如此，在现在很多情况下 IDE 看起来有所妨碍。当某个人需要在具有很多种语言和工具的不同环境之间切换时，最容易的就是抓到 Sublime 或类似的某个东西并运行。

在重量级有像 Visual Studio、Eclipse、IntelliJ、WebStorm 和其他应用工具等这样的 IDE。这些都很好，并且为一种或某几种语言提供了钩子以方便日常的运维编码工作。但是有可能当某一天快要结束时，某个不在那个 IDE 范围之内的语言突然冒出来，那就毁了你这一天。

另外一方面，如果一个团队能够专注于某个特定 IDE，使用它来加载任何开发所需要的一切，并且 IDE 能够和首选的云环境协同工作，那么 Visual Studio 和其他几个 IDE 就会脱颖而出。一个很好的例子就是用于 Visual Studio 的 AWS 的.NET 插件。这个特殊的插件是我所见过的仅有的没有将开发者绑定于实际云的工具集。它只是极大地简化了部署和查看云服务，这些都不用离开 Visual Studio。对于.NET 开发者来说，这是极大的好处，因为他们总是被鼓励并习惯于在云开发过程中一直呆在一种 IDE 中。

然而，在大多数 web 开发和云环境中，你会推送一些东西并使用像 SSH 这样的工具。在这种情形中 Visual Studio 和 Windows 通常都不是首选者（non-starter：比赛中不是首发的队员）。让 Windows 和 Visual Studio 与 SSH 和其他 Linux 或相关环境一起工作所花费的时间会非常让人沮丧。此时，非常戏剧性的是，像下面这样做反而容易得多，抓到一个终端，学会如何摆弄它，然后 SSH 连接到在这些终端，实际上就可以工作了。即使在使用 Windows Azure，如果你并不打算在 Windows 上寄宿或也不想使用 Visual Studio 的至 Azure 的私有钩子，那么完全可以甩开基于 Windows 的开发工具转而使用运行于 Linux 或 OS-X 之上的来自于 JetBrains 的工具。从这些工具上获取好处，你的开发团队最终会感谢你。云毕竟是源自于 Unix 并将在多年来已成为 Unix 技术世界一部分的很多理念的基础上继续演化着。

InfoQ：当开发者在构建云规模的应用时，应避免哪些反面模式呢？云提供商又如何避免你们犯这些错误，或反过来说，让你们做些错误的事情？

Hall：在开发云分布式应用时，开发者会掉入很多巨大的陷阱之中。

我曾一次又一次看到的最大问题是，他们更愿意搭建单一的数据中心（比如 AWS，一个区域等）。使用局限于某个数据中心的框架栈和故障转移所构建的某个应用仍然趋向于引起很多停机情况，比如“East 1 AWS Failure”，绰号为复活节故障。

另外一个很大的问题就是很多提供商——好吧，也许是所有的提供商——仍然还有很多 SPOFs（单点故障）。Windows Azure 在几个月前由于其证书问题而打破了大数据中心的故障记录。AWS 也出现过由于数据中心的某个网络设备而导致的故障。Rackspace 同样也有类似的问题，也鼓励了人们使用机架设备，这又在已有的其他故障点之上生成了更多的 SPOFs。整个想法是想让云架构具有弹性，而这些情况适得其反。

从纯粹的开发者角度来看，最大的错误在于很容易在云的计算和存储环境中只是简单地构建一个传统的垂直堆叠在一起的应用。在云环境中使用按照传统架构信条所构建的应用会付出高昂的代价昂贵，并且效率很低。然而一次又一次，我看到人们只是重新实现某个垂直设计的应用；Sharepoint，WebSphere 和其他所能想到的。他们通常只有单一的 RDBMS，在此之上有个数据层，以及一个或者可能是几个应用节点，而这几个应用节点却位于某个有着 SPOF 的缓存层之上。

总的来看，云开发中有很多反面模式，而运维和开发总是很容易实现它们。

Mårtensson：一个真正而又常见的反面模式就是将老的思考方式应用到新的范式上。比如认证；“我们想让顾客能够使用他们自己已有的 Google，Yahoo！，Facebook 和 Microsoft 帐号来认证我们的服务。当然我们也需要标准的用户名 / 密码登录方式。”你来找出其中的缺陷！基本上就是他们说想要设法变得很时髦，然后又想通过将自己的祖母带到聚会上来回归保守。如果这确实是你的开发和维护工作所要关注的，当然你可以运行并处理自己的用户名 / 密码认证服务。但如果你正在采用所有的方式来外部化自己的应用的认证，那么就需要通过将自己寄宿的认证服务（术语也称为安全令牌服务 STS）从你的应用中分离出来，然后才能真正实现这些方式。简而言之，你的应用不应关心任何认证。然而它应拥有一个可信任的、为你处理这个单独的关注点的标识符提供者。如果你不保存密码，则你根本不用保留此职责。最开初的表述是害怕由于不提供的标准的用户名 / 密码认证选项从而失去顾客。但这只会增加你的工作负荷，并且你将会失去使用云服务进行外部化认证的好处。如果你不能公正地对待这种新的模式，除了在开始就以完全错误的方式来使用它这种坏处之外，你最终还将会损害自己的业务。

Piper：好吧，说到现在我已经很难在 Adron 和 Magnus 所阐述的常见反面模式之外再添加其他内容了——这些我都见到过。有个很明确的倾向就是以传统的方式思考并构建垂直而不是水平扩展的应用。在这样的情况下，当一个开发者“发现”像 RabbitMQ 这样的异步消息传递和像 Redis 这样的内存中的数据结构，然后想到，哦，这是一种“全新”的做事方法时，我总是很吃惊。不，完全不是，这些概念已经出现了很长一段时间，而云平台比曾经任何时候都提供了一个幂等的、最终一致的服务模式。

在云提供商如何帮助你避免失误方面，就我自己来说，Cloud Foundry 尽了其最大努力尽可能地来提供作为其环境一部分的有用配置信息，所以你可以编码来从配置信息中去查找值而不用硬编码端口、数据库设置等。这并不妨碍你硬编码，但是这样做确实不是一件好想法。

InfoQ**：Redmonk的 Stephen O’Grady曾经说过“云计算的最重要特征：进入的低门槛。”你们认为哪些云对于开发人员来说学习会更容易一些？不仅只是让开发者注册，而且还向开发者展示了该如何开始部署应用这些方面，谁工作做得好？对于开发人员仍然还存在哪些进入门槛？**

Mårtensson：在瑞典我们说“'tala i egen sak”，意思就是说你是偏颇地来表达自己关于事情的看法。再次说明，我是一名虔诚的.NET/Visual Studio/C#开发人员。当然就会偏向 Windows Azure 云。仍然……哦！不用暴露我的年纪，我在这个持续的消防比赛中已经有很好的数十年的经历，而且我还从来没有在 Microsoft 看见过像这样的事情。也许巧合的是，微软的云的气息到来适逢其时？也许只是因为这就是应当做的？但我还从来没有在 Microsoft 身上见过如此致力于推动技术变迁的情况。并不仅是 VB 和 C#，还有很多。Microsoft 为现在的 Windows Azure 的多种平台和 IDE 构建和维护了工具集和 SDK。PHP、Java、Node.js、Ruby、Python & Visual Studio、Eclipse 和开发一次并可给很多不同类型设备发送消息的能力；这些设备有 iOS、Android、Window Phone 和 Windows 8。挑选你的毒药吧！今天谁是对 Linux 最大的开源贡献者？是的，这就对了，但是谁又曾知道这些呢？对于那些泡在这个空间的人以及那些知道 Microsoft 的人来说，这是一笔非常大交易！这是一个拥抱多元化的全新的 Microsoft，并且它意识到许多公司为了日常运营将会使用很多服务和平台来构建自己的现实世界。这就是我们现在所处的情形，而 Microsoft 就在这儿。有哪个其他的栈 / 平台能匹配这个呢？

Hall：对于任何 PaaS（平台即服务），进入门槛都尽可能如你所能达到的一样低。当我们深入探讨这些时，这会得到一些奇怪的比较结果。Window Azure 据称首先是 PaaS，然后才是 IaaS（基础设施即服务），它以这种方式开始，然后努力推广它。AWS 甚至都没有提到过 PaaS 这个词，即使他们拥有很多提供了 PaaS 风格的单一命令行（某些时候要点击）部署方式的服务和特征。而对于其他那些没有一个明确的 PaaS 说法的环境，门槛过多，而且很笨重，并且我觉得不太值得提及。所以对于那些没有一个合理的 PaaS 说法的我将会在其他时候再讨论。

这带来了另外一个关键之处，在 AWS 上实际运行的所有 PaaS 服务都是怎么样的。Heroku、EngineYard、AppHarbor、AppFpg 和几乎每个 Cloud Foundry 或 OpenShift PaaS 服务都安装在 AWS 上。所以很明显，如果某个应用包含了 AWS 的服务和 AWS 提供了 PaaS 服务的客户，那么它在可用性方面就大幅领先于其他人。即使我们回溯并只是看看首批 AWS 客户的安装和使用，这些客户在使用 Beanstalk、EC2 或 S3，其安装和使用都极其简单。签约、检查认证机制或类似于通过邮件发送的编码令牌，然后安装好上面所提到的项目之一并启动，你就已经在运行一个应用了。

可以说最严重的障碍都在基于 Heroku、EngineYard、Cloud Foundry 和 OpenShift 的 PaaS 中被移除了。在上面这样 PaaS 环境中可以很容易地安装、使用和部署应用，这些恰好都是位于 AWS 中。

但是对于 Windows Azure，Windows Azure 团队和努力将这些云选项从一个“绝对不”移动到“嘿，这是非常容易的且功能丰富的”。 Windows Azure，我不会再为回答这个问题而谈论其过去，它已经戏剧性地重新定义了如何更贴近部署，并积极地比几乎其他每一个 PaaS 或 IaaS 服务提供商提供了更多的部署选项和部署能力。另外其已转变为多语言的，在这场由 AWS 扮演兔子的龟兔赛跑中获胜。比如 AWS 节点 Beanstalk 功能。在 Windows Azure 能够极为容易地、优雅地和极好地在 AWS 上部署基于 Node.js 的应用差不多一年之后，AWS 才实现。加上它可以围绕 Node.js 来定价，对于小型的共享的云寄宿模型来说，.NET、PHP 和其他的应用已经为零。这对于开发者来说当然非常棒，他们可以在运营之前测试、调试大多数的应用。

总的来说，上面几乎涵盖了我个人所使用和一直关注的主要提供商的基本内容。Windows Azure、AWS、Cloud Foundry、OpenShlft、Heroku、EngineYard 都是现在值得关注的主要公司，它们正在这个空间内做着繁重的创新工作，并正在逐渐地前进以移除更多的进入门槛。

Piper：我喜欢 Redmonk 的这些家伙！他们都是非常聪明的人，并且我推荐那些任何不熟悉他们意见的人去寻找他们。开发者都是新的拥护者。

所以，是的，我完全同意进入的低门槛对于开发人员快速采用我们所讨论的云技术来说非常重要。实际上，这就是某个“啊哈时刻”，这可以让我从自己以前在 IBM 的角色转换到 VMware 的 Cloud Foundry 上来——本地编码应用的能力，无需任何改变地将其推送至云上，然后在几秒钟内将其扩展。鉴于我的角色，不用想就我可以说，很明显，Cloud Foundry 进入门槛很低……但就如 Adron 所说，我想很多相似的 PaaS 提供商都是这样，如 Heroku。我同样对为所见过的在 Visual Studio 和 Azure 环境中开发者所展示的工具集成所惊叹，在这个环境中开发者会觉得走向云的旅程十分愉快。我应该指出的是，很多云提供商，特别是 PaaS 提供商也拥有工作得很好的 IDE 插件。然而对于真正地低进入门槛，我仍然喜欢源自于 Github 命令行方式的克隆，本地构建和测试，然后从命令行推送至云的体验， Cloud Foundry 和几个其他云提供商都提供了这种——这比需要一个 IDE 更轻量级。

InfoQ：对于开发者来说哪些事情在过去曾经是很难的，而现在由于云变得简单多了？而且，有没有某些事情在过去是简单地忽略掉或者根本不做，而现在变得简单明了的？

Mårtensson：这是一个大局观的问题。当我们开发时什么是重要的？我们会在某一天回忆起云之前的“黑暗时代”并问自己在那个时代我们是曾经如何让一切运转起来的吗？构建一个全球可伸缩的供几十万甚至上亿用户使用的解决方案确实不是我们大部分人都曾经做过的。但是我们确实可以做到这一点。如果我们业务比像 Facebook 那样构建自己的数据中心要小得多的话，那么能有机会看到过自己能做到哪一步吗？如果有一个了解了云平台的力量的像样的架构师的话，我就敢说再开发这样的解决方案甚至都不再是什么难事了。现在没有新成立的公司会说“好吧，我们现在获得一笔风险投资，让我们出去采购一些服务器回来。”如果我们展望未来并设想我们开发将会所使用的环境，我确信 CPU 的能力、内存的大小、存储容量、甚至互联网的速度对于我们构建应用的方式的重要性会越来越小。相反我们会开始依赖于总会有足够的容量给我们正在做的无论什么东西，以及能满足我们的服务所要求的无论什么样的使用模式的需要。当然事情在未来仍然会出现中断，并且某些时候服务会出现故障。但不应会出现这样的情形，即我们不得不恐慌地冲到市中心去买一个全新的硬盘驱动器。我们的服务将会是自愈的。在这个大局观中我们会使用新的模式来开发，这些模式从开始就会把所有这些问题都考虑进来，而且我们从来也不会再关心是否拥有足够的计算能力。

Hall：我将建议的是排在前三名的事物：

1. 已经影响到开发人员能如何来开发的最大的影响是能力，即仅需在这儿或那儿点击一些选项或某个脚本就可以让整个运行开发环境跑起来。服务器、测试服务器、UAT 服务器等。在以前，即使在简单的虚拟化下这些在很多方式上都会受到限制。但是现在，在拥有 AWS、Azure 以及其他类似云环境所提供的云计算能力的情形下前面那些都完全不再是问题。以前需要耗时几小时或几天甚至几个月的事情现在几分钟之内就可以完成，并且以一种能向前移动并保留全部努力的方式工作，而这种方式在 6-7 年前完全无法想象可以这样做的。
2. 跨地理边界的分发系统的能力，这在 6-7 年前，即便不用花费数百万美元资本投资，也会需要数十万。现在每个月仅只需要几百或几千美元，一个庞大的、跨越广为分散的多个国家的分布式系统在几分钟之内就可以安装并运转起来，并准备好投入使用。
3. 与垂直叠高的方法相比，分布式系统正在成为普遍的做法。随着这种改变，隐藏在幂等、弹性、自愈、异步、可伸缩、高度可用性系统背后的思想在大大小小公司的绝大多数程序员中出现。随着越来越多的开发者转向水平扩展的做法，垂直扩展背后的极端受限的设计逐渐地被扔到路旁。随后一系列很多用来增强利用这些功能的能力的语言和框架应运而生。这种观念模式和方法的变化一直在持续进行着，并日益增强着云计算的能力。

……这就是在我脑袋中立刻能想到的排在前三的最重要的事物。现在已经发生那么多的变化，获得了很多的进展，以至于关于这个话题有人能写一本书了。

Piper：对于开发人员来说，云让哪些变得容易呢？

1. 按需的、潜在的可自由支配的环境。实际上，像 Vagrant 这样的本地工具还一如既往是开发者的朋友，但是能快速提供和千篇一律的克隆环境以及能以通常很小的代价运行这些环境的能力也极具价值。这对于开发和运维活动一直是巨大的推动力——开发者不用再面对运营维护者的突发奇想，开发者曾经得去为他们提供新的环境。这并不是为了敲打运营团队——新的云工具和环境也为他们提供更多的敏捷性。“作为服务”是 *aaS 缩写的关键部分。
2. 可伸缩性、可用性、弹性。我想 Magnus 和 Adron 对这部分已经说得很好。在这里除了将它们归结为这三原则之一之外，我无法再补充什么了。
3. 我认为有两件事——“大数据”和“物联网”——因为云的可用性在很大程度上变得更有能力。垂直扩展的大数据库这许多年来已经成为可能，但是具有海量存储容量、复制、MapReduce 等特性的分布式数据库更倾向于与云联系在一起。传感器的连通性、数据的采集和对数据的响应一直以来都是只以单点为基础，但是现在的开发者已经可以构建复杂的能实现自己想法的系统，使用云结构的灵活性构建的系统只有零或很少几个故障点。
4. 上面只是一个快速总结。这是一个技术演变具有深远影响的领域。

InfoQ：虽然很多开发人员都开始花费大量的时间来开发云应用，现实是还有很大一部分开发者在其日常工作中都没有理由去接触云。假定这部分开发者没有充足的自由时间来体验云环境，那么你们会推荐他们做什么以便与最新的云服务和战略与时俱进？你们自己又是怎样跟上这种不停向前流动的云空间的呢？

Hall：对于那些没有接触过云 / 公共云或刚出现的私有云的开发者来说，我发现两种很有用的方式非常重要。

1. 学习一般的分布式系统。这些包括分布式数据库、分布式计算（网格计算等）、通过自动化或大量其他选项进行的跨分布式环境的网络管理。这段时间也出版了很多书籍，这些都能在这上面给予他们很多帮助，因为很多工作都已经极大地学术化了（对那些实际上正试图利用分布式系统的编码人员或运营人员并不是很有用），但其中很多东西在日常的开发和运营中基本上没用。
2. 当这样做有用时候，尽量尝试在日常的开发过程中小规模地引入它们。即使没有用到云，从分布式角度而不是垂直式角度出发来构建某个系统也可以拥有强有力、有用性和健壮性这样的特性。下面就是我这段时间来一直坚决鼓励的一个做法的要旨：除非应用只是临时性的，否则请不要开发纯粹的垂直式应用。如果某个应用的期望生命周期超过一年的话，那么请按水平扩展的、可伸缩的架构来构建该应用，这样它在一个分布式系统环境之中也能很好地工作。

Mårtensson：向云迈出第一步很容易。首先我想提醒的是最大的问题是，从广泛和普遍采用云计算方面来看，我们目前处于哪个位置？我是一名云计算的倡导者和忠实信徒，并且我真的很想相信现在我们正准备促进云的大爆炸。这就是说很多即使不是所有的信号都在指着这个方向：培训公司在这上面的兴趣在显著增加，顾问们注意到更多关于云的喋喋不休，更多的客户正在激起兴趣而提供商的市场份额也在持续增长。我实在看不到一些关于正在快速增加地采用云技术的反面迹象。传统寄宿选项仍会继续挣扎求生并尽一切能力来显示自己仍是可替代的选项，但在我看来这只是延缓了它们无法避免的命运的到来。特别如果你认为混合场景也是一种真正的云场景的话，我想我们应也将看到一个快速应用需求。如果我们谈论技术采用生命周期，我认为我们在甲板上已拥有了早先的采用者，我们正站在深渊的边缘，深渊将早先的采用者们与其它分割开来。

云平台的提供商们正在尽力做到很容易就能采用并平滑地过渡到各自产品。比如 Microsoft 最近对于某些试用场合就取消了信用卡的要求。为了回答这个问题，开始与云计算同行将会实际上已经是很容易的了。你不需要花费大量时间来上手。你可以仅仅需用几分钟时间来注册并获得一个试用的可运行版本。实际上拥有一个已分配给自己的 MSDN 订阅的每个人都已在云中有一个个人的开发 / 测试环境。所需要的就是激活 MSDN 订阅上的 Windows Azure ，这大概需要 2 分钟左右。大量的在线指南可以帮助你将自己的第一个应用部署到平台。例如我博客上的视频演示。确实地如果你有 15 分钟的话，我敢打赌你肯定能将自己的第一个应用在 Windows Azure 云上正式运行起来。这可能是一件简单得也许微不足道的事情，但它真的很酷很让人耳目一新。

Piper：我想 PaaS 所提供的任何东西都是瞄着提供一个无阻力的部署表面——AppEngine、Cloud Foundry、Heroku、OpenShift 以及 Azure 的涉及 PaaS 的很多方面等等确实都是这样。如果在自己所选的平台上没有尽力提供一种在其上部署应用的简单方式，那么很有可能你开始就没有做对。当你开始寻找自己应用中的可伸缩性和数据访问方面某些问题时，学习曲线上仍然还有很多要去学习。

个人来说虽然我发现像 O’Reilly 这样的出版社所出版的很多不错的语言和编程指南书籍常常都有好几年的生存期，但由于云领域的快速创新，“云”相关的书籍显然还没有老到有这种火候。只要等待一个月，AWS 就会已引入一个全新的 API 或调降了价格，某个 PaaS 提供商就会宣布有了新的合作者、插件或功能！这就是说在博客中挖来挖去并跟随 Twitter 上的那些能推荐很好的链接的家伙会更有用。我发现两个特别的来源是很有价值的。Github 活动 feed 让我能跟随自己的联系人所评级或创建的新的项目、apps 和库。DevOps 每周简讯（云和开发空间的每周汇总邮件）也是一个获取关于最新进展的摘要信息的有用途径。

作者简介

Adron Hall：软件架构师、工程师、程序猿、码农、分布式系统的拥护者。他是位多产的开源贡献者，积极使用Github 来贡献项目。你可以在 CompositeCode.Com 上了解他的思想，还可以在 Twitter 上的 @adron 跟随他。

Magnus Mårtensson ：就职于瑞典的 Active Solution 顾问公司，担任云架构师 / 开发者。他是 Windows Azure MVP、Windows Azure 的业内人士、Windows Azure 顾问。你可以在 MagnusMartensson.com 上阅读其著述，还可以在 Twitter 上的 @noopman 跟随他。

AndyPiper：倡导 Cloud Foundry 的开发者。他的日常工作是包含以下内容的有趣混合：技术市场、业务开发、与开发者交谈、各种会议上的公开演讲、撰写文档和示例、向工程师抱怨其中断了事情、博客和推特、还有就是组织活动。从这儿可以了解他更多东西，还可以在Twitter 上的 @andypiper 跟随他。

查看英文原文： Virtual Panel: Adjusting to Development in the Cloud

感谢侯伯薇对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。