作者：Brett McLaughlin 他的著作上过畅销榜并获得过非小说类图书奖。他著述丰富，包括计算机编程、家庭暴力、分析和设计，总印数超过100,000本。他编写、编辑和出版技术书籍快十年了，除了惬意地使用文字处理程序写书以外，他还喜欢弹奏吉他、和两个儿子在屋子里追逐嬉闹、和妻子观看重新开播的 Arrested Development。他的新著 Head First Object Oriented Analysis and Design 荣获 2007 Jolt Technical Book 大奖。经典著作 Java and XMLL 仍然是关于在 Java 语言中使用 XML 技术的权威书籍。
2009 年 5 月 11 日
如果您恰好对云计算有基本的理解，您的技能完全用得着。但是，说到真正构建一 个应用程序，您使用什么平台？Google 和 Amazon 都名声在外，所以流行度不是问题。如果您是 Microsoft 拥护者呢？是否有适合您的选择？本文将带领您学习如何明智地看待云，并根据特定的应用程序需求选择适当的平台。
有关云计算的困惑
最近，人人都在谈论 “云”。不论是参加某个技术会议，或者与任何编程人员聊天，您的耳中很快就会充斥着诸如 “云计算”、“Google App Engine” 和 “Amazon 托管应用程序” 之类的术语。假设您已经清楚什么是云计算（本文的 参 考资料 小节就有很多文章可以帮助您弄清楚什么是云计算）。如果云计算最终只是一种编程语言的话，那么只需对它有基本的理解就可以真正编写代码。例如，一旦理解了 Java™ 对象的基础知识，就可以开始编写代码，并根据需要学习更多其他的知识。
但是云计算不是一种语言。实际上，它是一种范例。即使您理解了云计算是指在 Internet 上的远程服务器上运行并由它们托管的所有服务，但是在编写任何代码之前，仍然还需要做出很多的决定。首先，为云计算需求选择哪种平台？
有 Amazon 的解决方案，有 Google 的解决方案，也有 Microsoft® 的解决方案，还有像 AppNexus 和 GoGrid 这样的一次性解决方案。而它们并不是完全相同的！换句话说，不能像比较两个苹果一样简单地比较它们。实际上，试图按照不同的特性集合对它们进行分类就像在 一个非常大、非常混乱的迷宫中行走一样困难。但是，通过非常细心的考量，还是可以根据您自己 的特定的应用程序需求做出决定。
在各种不同的框架之间作出选择之前，至少需要理解可供选择的对象。本文的介绍比较简要，但是，您仍然应该使用 参 考资料 补充关于这些内容的信息。
Amazon EC2 是 Amazon Elastic Compute Cloud 的简称。“Elastic Compute Cloud” 不是一个很直观的名称，但 Amazon 的解决方案确实很有用。EC2 实际上是一个 Web 服务，通过它可以请求和使用云中大量的资源（换句话说，是由 Amazon 托管的资源）。EC2 提供从服务器到编程环境的所有东西。
Amazon 的解决方案的特色在于灵活性和可配置性。您可以请求想要的服务，根据需要配置它们，设置静态 IP，并显式地设置自己的安全性和网络 — 换句话说，您拥有很多的控制权。此外，Amazon 拥有很好的声望和良好的按使用量收费（pay-only-for-what-you-use）的模型，EC2 是云计算拼图中一个重要的、受欢迎的部分。
从技术上讲，Google 的 App Engine 是 Amazon EC2 的一个竞争对手，但是它们之间又有很大的不同之处。Amazon 提供灵活性和控制（在本文中您将了解很多这方面的内容），而 Google 则提供易用性和高度自动化的配置。如果使用 App Engine，您只需编写代码，上传应用程序，剩下的大部分事情可以让 Google 来完成。
和 Amazon 一样，Google 有很大的知名度，也有很大的缓存。与 Amazon 不同的是，Google 开始是免费的，只有当传输量较大，并使用较多计算资源时才收费。另一个不同点是，Google 是以 Python 为中心的架构和设计。若要使用 Google App Engine，则需要使用 Python。这个限制可以被视作一个局限性，也可以被视作一个有帮助的、简化问题的约束。
Microsoft 则以一种完全不同的方式实现云计算。就像 “I’m a PC, I’m a Mac” 这句广告词一样，Microsoft 致力于提供一个非常丰富的、专业的、高端的计算环境。因此，Amazon EC2 和 Google 针对的是那些仍然在
vi中使用 Python 并喜欢与网络协议打交道的人，而 Microsoft 的 Azure 产品则直接瞄准 Microsoft 开发人员。Visual Studio、可视化工具和可视化环境使得 Azure 对于每天使用 C# 和 SQL Server 的人来说非常亲切和舒服。就像 Amazon EC2 不同于 Google App Engine 一样，Windows Azure 与两者都不相同。最显而易见的是，Azure 就是 Windows®。它是基于 Windows 的；它针对使用 Windows 的人；它涉及 C# 和 SQL Server、.NET 以及 Visual Studio。Azure 就像是 SharePoint 加上一点 CRM。很快您就会看到，选择使用 Azure 很少是因为特性，而是因为您习惯使用的平台。
EC2、App Engine 和 Azure 是目前云计算领域的 “三巨头”。但是也许您不知道，并不是只有 它们三个。还有很多其他的选择，例如 GoGrid 和 AppNexus。如果您不知道其他这些工具，也无需过分担心。事实上，如果您是 “典型的” 想使用云计算的开发人员，您一般会选择 Google、Amazon 和 Microsoft 提供的这三个解决方案中的其中一个。如果您还知道这三巨头以外的其他东西，那么您甚至可能不需要阅读本文。
其他产品不同于 Google、Amazon 和 Microsoft，同样它们彼此之间也各不相同。所以，就像本文后面的内容强调的那样，您对平台的选择更大程度上取决于您的应用程序 需要什么，而不是您的平台提供 什么。
在本文后面的大部分内容中，您将遇到很多关于您的技能、偏好和应用程序需求的基本问题。每个问题让您进一步倾向于某个特定的 云计算平台解决方案。本文的想法是让您根据自己的应用程序的功能和您的技能集选择最佳的平台。
应用程序最终是围绕着数据的。应用程序显示数据、搜索数据、组织数据 — 几乎所有应用程序最终都会存储数据。那么，您已经做出的关于数据库的决定，对于选择哪个云计算平台有很大的影响。
如 果您只是构建应用程序，而没有已有的数据，那么您将有很大的自由度。您可以灵活地决定如何存储数据，甚至可以随意地成批导入已有的数据。所以，这对于您来 说不是问题。但是，如果您有很多已有的数据，则另当别论。
如 果您喜欢某种特定的数据库，甚至到了无法自拔的地步，那么在选择云计算平台时便要加以考虑。特别是，Google 的 App Engine 要求使用 Google 的数据库。Google 的数据库不好吗？它会损坏您的数据吗？它不支持 SQL 吗？都不是。但是，如果您习惯于对自己的数据库服务器进行细粒度的控制，并且也习惯了您喜欢的 MySQL 或 PostgreSQL 版本特有的 SQL，那么 Google 会让您失望。
然而，这正是 Amazon EC2 表现突出之处。Amazon 实际上只是在某处运行的一个盒子，它让您感觉非常类似于根访问。您可以安装任何需要的软件。更妙的是，可以将数据存放在 Amazon 的 Simple Storage Service（S3）中，它在数据方面有一套更完备的特性。但是，由于已经可以访问命令行，您可以做想做的任何事情。这意味着在进行数据库编程时可以最 大限度地模仿自己习惯的环境。可以在命令行测试 SQL 命令，获得类似终端的响应，并进行基本的管理。如果您只是想让您的数据可以工作，那么没什么大不了的，但是，如果您需要花大量时间研究您的数据库以及它的 幕后工作原理，那么任务可能非常艰巨。
由 于 Google 的特点是易于使用，有时候用命令行可以轻易完成的事情对于 App Engine 来说却很难。将数据导入到 Google 的数据库比较冒险，也容易出错，而且您自己不容易修复那些错误。另一方面，Amazon 的 EC2 大量使用了命令行访问。先进行批量的导入，然后修复错误，这种做法是可行的，甚至是受鼓励的。
图 1 给出了基本的决策树。
图 1. 您对当前的数据库有多大的热情？
在选择云计算平台时，Python 的问题是您将遇到的另一个决定成败的问题。简言之，Google 只支持 Python，它的一切都是围绕 Python 构建的。而 Amazon 则不是这样。虽然 Amazon 也允许使用 Python — 或者很多其他语言 — 但实际上 Google App Engine 最能体现 Python 的优势。所以，如果您想要一个方便的 Python 解决方案，那么 Google App Engine 是首选。
也就是说，除非……
有句话常被提到，现在也仍然管用：如果您渴望编译和运行程序之外 的控制、命令行和所有 Python 工具，那么 Amazon EC2 是王者。Amazon 乐于从命令行运行 Python 代码，这是 EC2 的优点，也是它的缺点。如果您喜欢在一个文件中编写文本，将它交给 Python，并使用系统错误和命令行进行调试，那么您会喜欢 Amazon，而且很可能会讨厌 Google 过于热心地 “帮助” 您。
如果您不需要 “由 C 语言编写的扩展”，或者觉得它是一种昂贵而不实用的奢侈品，那么可以跳到下一节。但是，如果您习惯于在 Python 中使用 C 扩展，那么应该清楚，Google 并不支持那些扩展。Google 主要还是限于 Python 标准库。虽然也有用于 Google 的 datastore、fetch 和 mail 服务的 API，但是除此之外没有更多其他的东西（一个值得注意的例外是 Django）。同样，这还是与控制有关。您是一名 Python 老手？Amazon 也许最适合您。开始使用 Web 服务，并且喜欢使用 Python，但是还不是特别精通这种语言？那么 Google 最好。
图 2 显示如何对上述情况进行分解。
图 2. 您使用 Python 吗？您想要多少 “额外的东西”？
这里有一个简单的问题：您打算在 “起点” 和/或 “终点” 使用 Microsoft 作为主导平台吗？如果是这样，那么 Azure 也许是最好的选择。我们来看看以 Microsoft 为 “起点” 和 “终点” 的真正含义是什么。
您是铁杆 Microsoft 开发人员吗？特别是，您是否在 Visual Studio 中使用 Visual Basic、Visual C# 或与 Silverlight 等相关的技术完成超过 2/3 的编程。如果是这样，那么您几乎肯定要选择 Windows Azure。您的整个开发框架都是基于 Microsoft 的，所以您会对 Azure 感到习惯。更重要的是，您不需要像使用 Amazon/Google 那样学习或重新熟悉很多非 Microsoft 的语言和技术。
这个问题按理说是多余的。大多数主要使用 VB、C# 等语言的开发人员都以 Microsoft 平台作为他们的用户基础。如果您想瞄准现有的 Microsoft 用户，并且不太担心跨平台兼容性，那么完全可以坚持使用 Windows Azure。Azure 有很多连接 Microsoft 平台的非常有用的钩子，所以由 Azure 托管的基于云的应用程序 可以无缝地与已有的 Microsoft 应用程序集成。对于普通的 Microsoft 用户，具有和已有的 Word、Internet Explorer 以及其他基于桌面的应用程序一样的感观，甚至可以与它们交互的基于云的应用程序具有很大的价值。
在 您开始曲解 Azure 之前 — 或者声称我曲解了 Azure 之前 — 您应该意识到，无论是起点还是终点平台，Azure 绝对不是仅限于 Windows 平台。您可以从任何平台访问基于 Azure 的应用程序，并且可以使用 C# 以外的其他语言进行开发；例如，Python 和 Perl 就可以。云的一个美妙之处就在于，语言和服务器技术都在云中。也就是说，它们对于大多数用户而言是透明的。
然而，认为以 Mac OS X 系统为目标平台的 Python 开发人员将使用 Windows Azure，这种想法最多是有一点愚蠢。实际上，只是没有那么聪明而已。如果将 Azure 的优势与某些不知名的新贵比较，那么 Azure 的纯专业特质也许会让您倾向于在以 Microsoft 为中心的、基于云的环境中使用非 Microsoft 技术。但是，不能这么看。您必须将 Azure 与来自 Google 和 Amazon 的同样成熟的解决方案相比较。在此情况下，显然最好使用在很多方面同样强大，而本质上则更加开放，可用于多种平台和非 Microsoft 技术的平台。图 3 更直观地阐释了这一点。
图 3. 喜欢 PC？您将喜欢 Azure
但是我不想使用 Azure！反过来也是一样：以 Microsoft 为目标平台的 Microsoft 开发人员并不是必须 使用 Azure。您也可以享受 Amazon EC2 的灵活性和威力，或者 Google App Engine 很 “酷” 的特性。如前所述，Amazon 和 Google 都提供一些引入注目的特性。虽然如此，还是要问一下 “为什么？”除非您打算学习新的技术 — 当然，这很有趣，通常也很值得 — 否则您很难找到理由构建一个纯 Microsoft 的解决方案，然后将它放入到一个非 Microsoft 的云中……更何况原本有一个很好的 Microsoft 云是现成的。与其在这方面付出这么多的努力，不如优化一下您的应用程序，或者重新构建一个应用程序。
在开始的数个月，Google App Engine 与 Amazon EC2 在两个关键的方面有所区别：
- Google App Engine 可以免费作为平台使用；而 Amazon EC2 则不可以。
- Google App Engine 有报价限制；而 Amazon EC2 则没有（至少在实际意义上没有）。
但是，到了 2 月末，虽然 Google 仍支持一开始的免费使用，但是当使用的资源超出免费范围时，则需要付费。这是 Google 的一个巨大的胜利，使他们从资源受限步入资源相关（resource-interesting）的阶段。
我使用术语 “资源相关” 表明，像 Google App Engine 这样的一种模式 — 一定范围内免费，超出范围则收费 — 对于几乎任何其他模型都有巨大的优势。首先，一开始使用 Google App Engine 是免费的。这意味着您可以试用 App Engine，在上面运行应用程序，甚至公开部署应用程序，所有这些都不用掏钱。所以这种 “一开始免费” 的方法有很大的优势。
然而，有趣的是，使用这种模式时，实际上可以不断估计带宽，逐渐扩展应用程序，直至超出免费范围。而 Amazon EC2 也允许根据需要扩展资源，所以一旦进入付费模式，Amazon 的解决方案与 Google 的解决方案之间并没有太大的差别。
Google 一开始免费的方法对于 Amazon 是一个优势：您可以先进行调优，并重整资源，延缓进入收费区域的进程。每个认真的程序员都知道，应用程序的第一个版本通常存在两种问题：
- 功能 bug。一些功能无法工作，或者无法正常工作，需要修复。
- 资源 bug。连接没有被关闭，或者池没有在使用，或者有什么东西在妨碍应用程序的运行，需要修复。
Google 的方法的好处在于，在为自己的错误买单之前，您可以跟踪这些资源 bug。
就此下结论？Google 只是稍微占优，但也许根本无法影响您的决定。
与 App Engine 和 EC2 一样，Azure 根据用量定价。使用 Azure 服务越多，价格越高。与 App Engine 和 EC2 的另一个类似之处是，Azure 根据计算机时间（CPU 使用）、带宽（包括进和出）和存储定价。它还根据事务（例如 GET 和 PUT）收费。
当然，这种定价方法还没有发布（截至 2009 年 3 月初），所以每个人还在拭目以待，看到底会怎么样。不过，老实说，预计定价会比 Google App Engine 和 Amazon EC2 高一点，但不会差太多。同样，定价很可能不会成为是否选择 Windows Azure 的决定因素，就像 Google 或 Amazon 一样。
这里很 容易一概而论。例如，您也许认为如果您喜欢 Python，并且是新手，就选择 Google；如果是 Python 高手，就选择 Amazon EC2；如果是 Microsoft 拥护者，那么使用 Azure。在很多情况下，这种过分简单的观点倒也适用。但是，如果完全以此为依据做出决定，最终可能会失望。Amazon 的确可以提供很强的功能，但是要想快速建立解决方案，还是 Google 更胜一筹。选择 Google 时所花的时间很短，而且很少出错。
Amazon 要求您知道自己在做什么。您可能需要打开几本书一边看着，更讽刺的是，您可能会经常使用 Google 弄清楚每件事（是搜索引擎，而不是 App Engine）。但是，额外的工作可以赋予您更大的能力，以及事实上无限的资源。
简单来说，Azure 因 Windows 平台而显得出色。虽然有一些瑕疵，但是它对于 Microsoft 程序员来说比较直观，而且应用程序用户从平台的角度来看会觉得它比较舒服。
那么，您怎么做？一个好的程序员总是这样做：多学习一些工具，在合适 的情况下使用它们。这胜过用占卜的方式来决定。从 Google App Engine 入手，有一定基础后，用 Amazon EC2 作为平台开发同样的应用程序。打开 Visual Studio，看看用 C# 可以做些什么，然后将您的应用程序部署到 Azure。所有这三个主流平台都体验一下，当您有一个有特定需求的应用程序时，就可以受益匪浅。
macd11.com 和 丁火甲木庚金 公众号版权所有丨如未注明 , 均为原创丨转载请注明原文链接。您必须 登录 才能发表评论！
