acm-header
登录

ACM通信

实践

公寓和云


云和公寓,插图

回到顶部

住在公寓里(通常被称为共管公寓)有它的限制和它的服务。通过定义生活方式和使用模式的限制,可以将许多家庭紧密地聚集在一起,并为居民提供许多便利。Condo living可以为那些有兴趣和愿意在其限制内生活并享受共享公共服务的人提供很大的价值。

类似地,在云计算中,应用程序运行在共享的基础设施上,可以获得许多灵活性和成本节约的好处。为了最大限度地利用这种安排,需要有一个明确的使用模式和约束,以授权共享和礼宾服务。正是使用模式的清晰性使新的平台即服务(Platform as a Service, PaaS)产品能够支持应用程序模式并提供服务,从而简化了符合该模式的应用程序的开发和操作。

就像使用建筑物有许多不同的方法一样,应用程序模式也有许多风格。本文将介绍一个实现软件即服务(Software as a Service, SaaS)应用程序的典型模式,并展示如何通过将该应用程序约束于此模式,从而提供许多礼宾服务,从而简化基于云的应用程序的开发。

在过去的50年里,按照预期的使用模式建造建筑已经变得越来越普遍。并不是所有的建筑都符合这种模式。有些建筑的要求是所以独特的是,它们只需要按需建造,钢铁厂,棒球场,甚至超级沃尔玛都是如此专业,你不能指望通过房地产中介找到一个。

然而,这样的定制建筑正变得越来越罕见,而越来越多的建筑,无论是工业园区、零售办公室还是住宅,都在以一种共同的方式建造,并牢记使用模式。他们的设计理念很明确如何它们会被使用,但不一定将使用它们。每一种都有居住者的标准规格,新的居住者必须适应空间。

一栋建筑的使用模式可能会带来限制,但反过来,它提供了共享的礼宾服务。例如,一个公寓住宅开发项目对停车、噪音水平和烧烤进行了限制。居民不能从事车库项目或园艺项目。作为交换,总有人在身边接受他们的包裹和干洗。他们可能会共用一个健身设施和游泳池。东西坏了就会有人来修理。

一栋办公大楼可能共用浴室、复印室和大堂。建筑的工程通常是整个结构。为了获得这些共享利益,租户可能会有固定的办公室布局,以及一些使用规则。正常情况下,人们不能在工作时间睡觉,不能在工作时间养宠物,甚至可能对办公大楼有着装要求。

零售商场提供共享的工程、停车、安保和公共空间。广告预算可能会使所有商场租户受益。作为交换,有共同的时间、允许的零售活动的限制和对每个商店外观的限制。

每一种建筑类型都有使用模式的限制,并提供礼宾服务作为交换。要享受好处,你需要接受约束。

类似地,云计算通常有一定的限制,因此可以提供礼宾服务作为回报。共享基础设施可以做些什么来简化共享应用程序?共享应用程序必须满足哪些约束才能适应共享云?

回到顶部

什么是云计算?

云计算通过内部网或Internet以服务的形式交付应用程序。已经出现了许多术语来描述云计算解决方案的各个层次。

  • SaaS.这指的是用户跨Internet或intranet访问应用程序的能力。SaaS已经存在多年了(尽管它的术语是最近才出现的)。新的功能是无需构建数据中心就可以将应用程序投射到Web上。
  • PaaS.这是一个新兴领域,供应商提供高级应用程序服务的目的有两个:第一,好的PaaS可以使应用程序的开发更容易;其次,一个好的PaaS可以让云提供商更容易高效地共享资源,并为应用程序提供礼宾服务。今天,PaaS的领先例子是Salesforce的Force。com5和谷歌的App Engine。2
  • IaaS(基础设施即服务)。有时被称为效用计算,这是通过Web提供的虚拟化硬件和计算。IaaS的用户可以根据需要访问虚拟机(vm)和存储。

图1展示了云与SaaS提供商和用户之间的关系。(这个数字来自加州大学伯克利分校的一份技术报告,“云之上:伯克利云计算的观点”。3.正如在“云之上”中所观察到的,云计算有三个新的方面:一种无限计算资源随需应变的错觉;消除云用户的前期承诺;以及在短期基础上支付计算资源的能力。

云计算允许saas的部署和按需扩展,而无需构建或供应数据中心。

公有云和私有云.云是关于分享的。问题是你是否分享一家公司或去第三方供应商分享公司。

在公共云中,云计算提供商拥有数据中心。其他公司使用他们的计算和存储,收取现收现付的费用。这具有巨大的规模优势,但管理信任关系更具挑战性。信任确保计算资源在需要时可用(这可以称为SLA,或服务水平协议)。此外,还有隐私信任的问题,订阅公司需要有信心,其私人数据不会被窥探者访问。如果公司拥有数据中心,展示隐私就更容易。

公共云可以将其共享资源投影为vm和底层存储,要求应用程序构建在物理机器池上(即使它们实际上是虚拟的)。这将是一个公共云的IaaS。亚马逊的AWS(亚马逊网络服务)1就是一个很好的例子。

或者,在公共云PaaS中,可以向允许比VM更细粒度的多租户的应用程序提供更高级别的抽象。这些抽象概念的形状和形式正在迅速演变。再一次,Force.com和App Engine就是新兴的例子。

在私有云中,数据中心、物理机器和存储都由使用它们的公司所有。共享发生在公司内部。根据不同的部门和应用程序,资源的使用可以有涨有落。共享云的大小可能小于公共云,这可能会降低共享的价值。尽管如此,它仍然对许多公司具有吸引力,因为它们不需要信任外部云提供商。到目前为止,我们只看到了私有云IaaS。新的PaaS产品还不能供各个公司在其私有云中使用。

驱使我们走向云端的力量.许多力量都在推动应用程序向云的转移:

数据中心经济学.非常大的数据中心可以以相对划算的价格提供计算、存储和网络。电力在数据中心成本中所占的比例越来越大,将数据中心放置在水电大坝等廉价的电力来源附近可以更有效地获得电力。在互联网主线附近,互联网入口和出口比较便宜。将数千台机器装在集装箱中交付的集装箱服务器可以降低计算和存储的成本。共享服务器管理可以节省操作成本。所有这些都包含在数据中心的巨大价格标签中。很少有公司能负担得起这么大的投资。对大的投资进行分摊(并收取费用)可以降低成本。这为云提供商和用户提供了经济动力。

共享数据.越来越多的公司发现维护“大数据”商店的巨大(和偶然的)价值。越来越多的企业数据被放在一个存储中,这些数据可以在大型计算中统一处理和分析。在许多情况下,发现的价值随着数据存储的增加而增加。将企业的所有数据存储在一个公共存储中,允许分析,并看到惊人的价值,这正在成为一个目标。

共享资源.通过将计算和存储合并到共享云中,可以提高这些资源的利用率,同时为高优先级的工作维护强大的sla。低优先级的工作可以在空闲时间完成,而在繁忙时间则会被高优先级的工作抢占。这要求资源是流动的和可替换的,以便将较低优先级的工作放到一边,并将资源重新分配给较高优先级的工作。

SaaS:前端、后端和决策支持.让我们更仔细地看看SaaS实现中的一个典型模式。通常,应用程序有两个主要部分:处理传入Web请求的前端;以及后端,它进行离线后台处理,准备前端所需的信息。除了为前端准备数据的工作外,后端应用程序通常与决策支持处理共享(参见图2).


电力在数据中心成本中所占的比例越来越大,将数据中心放置在水电大坝等廉价的电力来源附近可以更有效地获得电力。


在典型的SaaS实现中,前端提供处理Web服务或HTML的面向用户的服务。这种web服务代码通常具有激进的sla,通常只有300ms500ms,有时甚至更紧。后端处理使用抓取的数据、伙伴提要和前端和其他源生成的日志信息,并生成供前端使用的参考数据。您可能会看到产品目录和价格表作为参考数据,或者您可能会看到支持谷歌或Bing搜索等系统的反向搜索索引。除了生成引用数据外,后端处理通常还为SaaS所有者执行决策支持功能。这些允许“假设”分析来指导业务。

回到顶部

SaaS应用程序中的模式:前端

在这里,我将探讨一个用于构建SaaS应用程序前端部分的常见模式。通过利用这些应用程序使用的模式,PaaS管道可以提供许多非常有用的礼宾服务。

许多服务应用程序很好地适合于一种行为模式。这些应用程序的目标是实现SaaS应用程序的前端。传入的web服务请求或HTML请求到达系统,并使用会话状态、其他服务和缓存的引用数据以请求-响应模式进行处理。

当前端应用程序符合刚才描述的模式的约束条件时,需要很多礼宾服务可以提供给应用程序。这些服务简化了应用程序的开发,缓解了服务的运营挑战,促进了云资源的共享,有效地满足了应用程序定义的sla。一些可能的礼宾服务包括:

自动伸缩.随着工作负载的增加,会自动为该服务分配其他服务器。当负载下降时,资源被收回。

Auto-placement.部署、迁移、断层边界和地理透明度都包括在内。应用程序是幸福的无知。

容量规划.这包括分析返回到传入用户工作负载的服务使用的流量模式。跟踪传入用户工作负载的趋势。

资源市场.礼宾服务管道自动跟踪服务的成本,因为它直接消耗资源和间接消耗资源(通过调用其他服务)。这样就可以将共享服务的成本归因于煽动工作,并向其收取费用。

A/B测试和实验.通过该管道,可以很容易地在流量的子集上部署服务的新版本,并将结果与前一个版本进行比较。

自动缓存和数据分发.SaaS应用程序的后端生成供前端使用的参考数据(例如,产品目录和价格表)。该数据以可伸缩的方式自动缓存,对引用数据中的项的更改自动分发到缓存中。

会话状态管理.在处理与合作伙伴的每个请求时,它可以选择记录描述该合作伙伴正在进行的工作的会话状态。这是自动管理的,以便后续请求可以轻松获取状态以继续工作。会话状态管理器使用动态可伸缩和负载平衡的服务。它实现了应用程序的会话状态存活和容错策略。

这些礼宾服务都依赖于应用程序遵守典型前端SaaS应用程序所描述的使用模式的约束。

回到顶部

无状态请求处理

服务的传入请求被路由到能够响应请求的多个服务器中的一个。此时,没有任何状态与目标服务器中存在的会话相关联(如果需要,我们将在以后获得它)。可以合理地认为这是一个无状态请求(至少到目前为止),并选择任何可用的服务器。

管道保持一个可以实现服务的服务器池。传入请求是动态路由和负载平衡的。随着需求的增加和减少,管道的礼宾服务可以自动增加和减少服务器的数量。

复合请求处理.通常,一个服务调用另一个服务来完成工作。被调用的服务可以反过来调用另一个服务。这个复合调用图可能会变得非常复杂和深入。这些服务中的每一个都需要完成以构建用户的响应。当请求进入时,工作散开,得到处理,然后再次收集。2007年,亚马逊报告称,对其电子商务网站的一个典型请求会导致超过150个服务请求。4许多SaaS应用程序遵循中所示的模式图3一

  1. 请求从外部(Web服务或HTML)到达。
  2. 服务可选地请求其会话状态以刷新关于正在进行的工作的内存。
  3. 响应从会话状态管理器返回。
  4. 如有需要,可咨询其他服务。
  5. 另一个服务响应。
  6. 咨询应用程序数据缓存(由后端处理管理)。
  7. 缓存的引用数据返回给服务,供其前端应用程序使用。
  8. 响应被发送给调用者。

sla和请求深度.SaaS前端服务的请求将具有SLA。典型的SLA可能是“假设流量速率为每秒500个请求,对99.9%的请求作出300ms的响应”。

在构建服务时,通常使用百分数(例如99.9%)而不是平均值来度量SLA。平均值更容易设计和部署,但会导致用户不满,因为离群的情况通常非常烦人。

回到顶部

打击底层的军种

要使用复合调用图实现系统范围的SLA,底层的压力很大。因为在调用者的SLA中考虑了时间因素,堆栈越深,SLA的压力就越大。

在许多系统中,最低级别的服务(例如会话状态管理器和引用数据缓存)的sla的99.9%可能是5ms10ms。图4展示了复合调用图如何变得非常复杂,并给调用堆栈带来很大的SLA压力。

回到顶部

简单排队理论快速复习

预期响应时间取决于最小响应时间(空系统上的响应时间)和系统的利用率。事实上,等式是:

ueq01.gif

这是很直观的。如果系统是50%的繁忙,那么工作必须在空闲时间完成,所以它需要最小时间的两倍。如果系统90%繁忙,那么工作必须在10%空闲时间完成,所需时间是最小值的10倍。

自动配置以满足sla.当服务的SLA出现下降时,一种解决办法是减少提供服务的服务器的利用率。这可以通过向服务器池中添加更多服务器和分散工作来实现。

假设每个面向用户或面向外部的服务都有一个SLA。另外,假设系统管道可以跟踪调用模式,并知道哪些内部服务由面向外部的服务调用。这意味着管道可以知道嵌套内部服务的SLA需求,并跟踪栈中深层服务的需求。

考虑到优先级需求和各种面向外部的服务的sla,管道可能会增加分配给重要服务的服务器数量,并借用或窃取低优先级工作的服务器数量。

访问数据和状态.当一个请求降落到一个服务中时,除了与请求一起到达的状态外,它最初没有其他状态。如果需要,它可以获取会话状态和/或缓存的引用数据。

会话状态提供来自此服务在会话中以前的交互的信息。它在请求开始时获取,然后在请求完成时与其他信息一起存储回去。

大多数SaaS应用程序使用特定于应用程序的信息,这些信息在后台准备并缓存供前端使用。产品目录、价格表、地理信息、销售配额和处方药相互作用是参考数据的例子。通过键访问缓存的引用数据。使用该密钥,前端内的服务可以读取数据。在前端,该数据是只读的。应用程序的后端部分生成引用数据的更改(或新版本)。上可以看到一个只读缓存引用数据的示例Amazon.com零售网站。查看任何产品页面的ASIN(亚马逊标准识别号),一个通常以“0”或“b”开头的10个字符的标识符。这个唯一标识符是您看到的所有产品描述(包括图像)的键。

管理可扩展和可靠的状态.会话状态由会话状态ID进行键控。该ID在请求时进入,用于从会话状态管理器获取状态。会话状态的一个例子是电子商务网站上的购物车Amazon.com

会话状态管理器的管道处理伸缩。随着会话数量的增长,会话状态管理器会自动增加其容量。

此管道还负责会话状态的持久性。通常,持久性要求要求会话状态在单个系统故障后仍然存在。是否应该将其写到云中的一组系统上的磁盘上?它是否应该保存在许多系统的内存中以提供可接受的持久性?持久性的增加需要更多的系统实现成本,并可能需要增加延迟以确保请求是持久的。

通常,会话状态管理器的使用非常频繁,因此它必须为读和写提供非常积极的SLA。5毫秒或10毫秒的保证并不罕见。这意味着等待将会话状态记录到磁盘上是不现实的。当会话状态出现在内存中的两个或三个副本上时,通常会确认会话状态已成功写入。之后不久,它可能会被写到磁盘上。

将更改应用到后端.有时,前端请求实际上“工作”并将应用程序更改应用到后端。例如,用户推送Submit并要求完成其工作。

应用程序对后端的更改可以是同步的,即用户等待后端完成工作并响应请求;或者异步的,在这种情况下,工作将被放入队列并稍后处理。

Amazon.com提供一个异步后端应用程序更改的示例。当用户按下Submit键时,前端的一部分会快速确认收到了工作,并回复请求已被接受。通常,后端会及时处理请求,用户会在一两秒钟内收到电子邮件消息。偶尔,当后端的异步处理繁忙时,电子邮件消息需要30分钟左右。

自动服务、状态和数据.通过理解SaaS应用程序的使用模式,平台可以减少开发应用程序所需的工作,并增加其优点。书中建议的那样图3 b,应用程序应该只关心它的业务逻辑,而不是系统级问题。调用其他服务、访问缓存数据和访问会话状态的接口很容易调用。这为可伸缩和健壮的SaaS应用程序提供了支持。

应用程序会话状态、应用程序引用数据缓存和对其他服务的调用可用作礼宾服务。平台规定了如何访问这些服务,应用程序不需要知道构建它们需要什么。通过对应用功能的约束,平台可以增加礼宾服务。

回到顶部

SaaS应用程序中的模式:后端

本节将探讨典型SaaS应用程序的后端部分使用的模式。这个后端为应用程序做什么?它通常是如何做到的?

SaaS应用程序的后端接收来自多个来源的数据:

  • 爬行.有时后端应用程序会查看Internet或其他系统,以查看可以提取的内容。
  • 数据传输.合作伙伴公司或部门可能会将数据发送到后端系统。
  • 日志记录.关于前端系统行为的数据积累。这些日志由后端系统提交以供分析。
  • 在线工作.有时,前端直接调用后端来代表应用程序的前端部分执行一些工作。可以同步(在用户等待时)或异步调用。

所有这些数据源都被输入后端,在那里它们被记忆和处理。

许多前端应用程序使用SaaS应用程序后端定期更新的引用数据。应用程序被设计用来处理可能过时的引用数据。处理参考数据的一般模型为:

  1. 来自合作伙伴的提要、Web爬行或来自系统活动的日志的传入信息到达后端。在线工作也可能刺激后端处理。
  2. 后端应用程序代码以批处理作业或延迟较短的事件处理方式处理数据,或者两者兼有。
  3. 引用数据缓存中的新条目被分发到缓存机器。这些更改可能是通过批量更新或增量更新产生的新版本。
  4. 前端应用程序读取引用数据缓存。这些都是逐步更新的,前端的用户看到新的信息。

引用数据缓存是键值存储。对于这些缓存,一个易于理解的模型对缓存中的数据进行了分区和复制。每个缓存机通常都有一个内存中的存储(因为磁盘访问太慢)。随着缓存数据大小的增加,分区的数量也会增加。副本的数量最初会增加,以确保容错,然后支持从前端读取流量的增加。

这是可能的支持这种模式在管道与完整的礼宾服务。后端的管道可以处理用于数据规模的分区(以及用于增长或收缩的重新分区)。它可以处理启动新的副本以达到读取速率的规模。此外,管道还可以管理后端所做更改的分发(以批处理或增量方式)。该分发版理解分区、动态重分区和动态分配给分区的副本数量。

图5说明了SaaS应用程序中从后端到前端的接口通常是一个键值缓存,它由后端填充,而前端是只读的。这种清晰的模式允许在PaaS系统中创建礼宾服务,从而简化了这些应用程序的实现和部署。

注意,这不是动态缓存管理的唯一方案。一致哈希(如Dynamo实现的,4卡珊德拉6, Riak8)在处理参考数据时提供了一个很好的选择。有些过时的引用数据(前端是只读的,后端是更新的)的一致性语义是非常好的匹配。这些系统具有良好的自管理特性。

后端处理风格.SaaS应用程序的后端部分可以通过多种不同的方式实现,这在很大程度上取决于所需处理的规模。这些包括:

关系数据库和普通应用程序.在这种情况下,计算方法是相当传统的。数据保存在关系数据库中,计算以一种可靠的方式完成。您可能会看到数据库触发器,N-tier应用程序,或其他申请表。通常在云环境中N-tier或其他形式的应用程序将运行在VM中。这可以生成前端所需的参考数据,以及假设业务分析。这种方法具有关系数据库的优势,但只能扩展到少数大型机器。

大数据和MapReduce.这种方法是一种面向集合的大规模并行处理解决方案。底层数据通常存储在GFS(谷歌File System)或HDFS (Hadoop Distributed File System)中,计算是通过使用MapReduce、Hadoop或其他类似技术的大型批处理作业来执行的。越来越多的高级语言以声明的方式表达所需的计算。这可以用于生成参考数据和/或执行假设业务分析。随着时间的推移,我们将看到MapReduce/Hadoop的出现所有企业数据的。

大数据和事件处理.数据仍然保存在可扩展的存储中,如GFS或HDFS,批处理可用于生成参考数据和进行假设分析。有趣的是,它能够在几秒钟内识别提要或Web爬行的更改,并对MapReduce/Hadoop批处理作业可用的相同后端数据库执行事务性更新。一个值得注意的例子是谷歌Percolator项目。7将事件快速处理为新的引用数据提供了活跃的Web体验。

当SaaS应用程序的后端部分遵循所描述的模式时,就可以创建一个PaaS产品,使构建、部署和管理应用程序变得更加容易。通过生活模式的限制,有很多礼宾服务可供选择,例如:

大数据统一数据访问.对于统一的企业范围(和跨企业控制)数据,任何东西都可以用任何东西处理(如果得到授权)。

容错和可扩展的存储.大数据和关系型数据库都可以使用云管理存储,可以实现数据中心内和跨数据中心的自动复制。

大规模并行批处理.高级集合操作执行大规模计算。

事件处理.对于独立事件,可以使用具有极高更新率的低延迟操作。事务性更新会使用超过几十pb的数据(参见Percolator7).对同一数据语料库的事件处理可用于批处理。

自动扩展引用数据缓存.后端为前端提供动态更新的特定于应用程序的数据。键值缓存的管理和操作是自动的。该管道确保通过增加缓存的复制来维护前端的读sla。

多租户访问控制.企业间(公共云)和企业内(私有云)都需要对共享存储中包含的数据进行访问控制。

优先sla驱动的资源管理.关系数据库、大数据批处理和大数据事件处理争夺相同的计算资源。不同的组织有不同的工作负载,都在争夺资源。各种工作负载都被赋予SLA和优先级,然后通过管道自动进行权衡。

回到顶部

在计算领域走向共性的驱动力

就像建筑物具有共同性一样,不同类别的计算环境也具有共同性。不同的班级必须与社区联系在一起,就像在建筑中发生的那样。云环境正在日益促进这些变化。

今天的企业使用SOA(面向服务的体系结构)将应用程序筒仓粘合在一起。竖井是在共享数据库上工作的应用程序的集合。SOA是应用程序集成,它包含使用消息传递和数据feed的EAI(企业应用程序集成)和B2B(企业对企业)通信。图6展示了具有共享特征的应用程序将如何聚集在SOA服务总线中。当前的企业应用程序将在迁移到云的过程中利用它们的通用性。当然,不是为云部署而设计的现有应用程序无法获得与那些遵循新的和正在出现的模式的应用程序相同的好处。尽管如此,仍然有一种方法可以利用现有的共性,并通过在公共或私有云内的云部署获得新的好处。


随着企业计算的各个部分转移到私有或公共云中的公共托管,应用程序的行为、跨它们的交互以及应用程序的使用模式都可以被跟踪。


云计算将有助于推动竖井和SOA形成一种通用的表示:

关系数据库.关系数据库将在标准化服务器上得到支持,这些服务器具有运行在san(存储区域网络)上的标准化存储。这将允许健壮的存储作为可重新启动的数据库服务器的基础。

使用虚拟机的现有应用.因为现有应用程序对处理环境有自己的期望,所以使用VM最容易满足这些期望。对于应用程序软件来说,VM看起来就像一台物理机器,但是可以在云的集群中进行管理。应用程序可以获得一台机器或一组机器。

通过大数据存储的SOA消息传递.大型云存储可以接收用于连接企业各部门的消息和数据。通过让SOA服务总线通过大数据存储,可以获得有关竖井交互的信息,以便进行分析。这类分析已经被证明在为企业带来洞察力方面是无价的。

标准化监控与分析.随着企业计算的各个部分转移到私有或公共云中的公共托管,应用程序的行为、跨它们的交互以及应用程序的使用模式都可以被跟踪。在大数据存储中捕获这些数据,允许以与应用程序的消息传递数据和其他企业知识集成的方式进行分析。

数据库与大数据.关系数据库提供严格控制的事务和完整的关系语义。然而,它们确实面临着扩展到少数服务器之外的挑战。尽管如此,关系数据库在应用程序、操作和技能开发方面已经有30多年的投资,这些投资将持续存在很多年。

以MapReduce和Hadoop为代表的新兴大数据存储提供了互补的优势集。利用具有高可用性的复制数据的大规模文件系统,这些环境提供了可以在公共名称空间中处理的数百pb的数据。最近,出现了提供事务保护更新的可更新键值存储。7这些庞大的系统经过优化,可以让多个用户以优先方式访问计算和存储资源。

大数据环境的这些好处将越来越多地应用于现有应用程序中使用的关系数据库数据的副本。业务线关系数据与企业其他数据的集成将产生一个通用的数据背板。

企业中的业务线部门推动新应用程序的开发。这个部门需要应用程序及其提供的解决方案来满足业务需求。部门为应用程序提供资金,通常不太关心应用程序如何适应企业的其他计算工作。

另一方面,一旦应用程序部署完毕,IT部门就必须处理和操作它。它希望应用程序、数据库和服务器处于共同基础上。它需要将应用程序集成到企业范围的监视和管理中。

这种天然的紧张关系,与房地产开发商与城市规划委员会之间的紧张关系类似。开发商希望建造和销售建筑,对质量不太挑剔。城市规划者必须确保开发商考虑到社区规划以及污水处理厂是否有足够的处理能力等问题。

当我们迁移到云计算环境(其中应用程序、数据库管理系统和其他计算资源托管在一个公共的服务器集合上)时,我们将看到关于如何将它们与企业联系起来的标准和期望的增加。

那把我们推向云端的力量呢?当他们专注于计算和存储的共同和共享基础时,这些力量将会有他们自己的方式。首先,集中而昂贵的数据中心通过更便宜的电力、网络和服务器技术节省的成本将会继续。尽管存在管理信任的问题,但经济因素是一股强大的力量。第二,企业会在数据分析中不断发现意外的价值。可供分析的数据越多,有价值的惊喜就会发生得越多。最后,计算和数据存储资源将越来越多地在应用程序和企业之间共享。现有的应用程序将获得一些共享价值,新的云感知应用程序甚至更多。

这些力量将鼓励应用程序在共享的新抽象基础上一起工作。当应用程序坚持它们的旧模式时,它们将从云的共性中获得一些优势,但不会像新应用程序看到的那样多。

回到顶部

结论

环境中的约束是赋予服务能力的因素。使用模式允许支持基础设施和礼宾服务。

共享建筑通过限制和标准化使用而获得成功。建筑设计师知道如何一座建筑将被使用,即使他们不知道将会使用它。不是每个人都能接受这些约束,但对于那些接受约束的人来说,这里有非常棒的优势和服务。

计算工作使用的标准化将使工作迁移到共享云。通过这些使用模式,支持服务可以极大地降低在云中开发和部署应用程序的障碍。较低层次的标准随着虚拟机的出现而出现。它们支持广泛的应用程序,但共享的灵活性较低。高级PaaS解决方案刚刚起步,但提供了许多优势。

我们必须定义和约束重要类型的云应用程序的使用模型。这将使重要的支助服务加强资源共享。新的PaaS产品将为计算世界带来巨大的价值。

ACM队列的q戳相关文章
queue.acm.org

评论:没有路线图的旅行
彼得·克里斯蒂
http://queue.acm.org/detaiL.cfm?id=1515746

战斗物理:一场艰难的战斗
乔纳森·m·史密斯
http://queue.acm.org/detail.cfm?id=1530063

CTO圆桌会议:云计算
2009年1月10日
http://queue.acm.org/detail.cfm?id=1551646

回到顶部

参考文献

1.亚马逊网络服务;http://aws.amazon.com/

2.App Engine;http://code.google.com/appengine/

3.Armbrust, M., Fox, A., Griffith, R., Joseph, A. D., Katz, R. H, Konwinski, A., Lee, G., Patterson, D., Rabkin, A., Stoica, I.和Zaharia, M.在云之上:伯克利对云计算的看法;http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.pdf

4.DeCandia, G., Hastorun, D., Jampani, M., Kakulapati, G., Lakshman, A., Pilchin, A., Sivasubramanian, S., Vosshall, P.和Vogels, W. Dynamo:亚马逊的高可用键值商店。ACM操作系统原理研讨会http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

5.Force.comhttp://www.force.com/

6.Lakshman, A.和Malik, P. cassandra分散式结构化存储系统。大规模分布式系统和中间件http://www.cs.cornell.edu/projects/ladis2009/papers/lakshman-ladis2009.pdf

7.Peng, D.和Dabek, F.使用分布式事务和通知的大规模增量处理。在9年会议记录th操作系统设计与实现研讨会(2010);http://research.google.com/pubs/pub36726.html

8.Riak;http://basho.com/products/riak-overview/

回到顶部

作者

帕特Helland自1978年起在分布式系统、事务处理、数据库和类似领域工作。他是Tandem Computers的TMF(事务监控设施)的首席架构师,该工具为不间断系统提供分布式事务。在微软,他曾担任Microsoft Transaction Server、SQL Service Broker和Cosmos(分布式计算和存储系统)的首席架构师。他最近加入了Salesforce.com并领导了一系列研究大规模数据的新工作。

回到顶部

脚注

这篇论文是在赫兰加入之前写的Salesforce.com虽然有很多相似之处,但这并不是对Salesforce架构的描述。

回到顶部

数据

F1图1。云计算、效用计算和软件即服务。

F2图2。SaaS计算和存储。

F3图3。(a)典型的前端SaaS应用模式。(b)应用程序的重点是业务逻辑。

F4图4。复合图表。

F5图5。从后端到前端的SaaS应用程序接口。

F6图6。筒仓和SOA。

回到顶部


©2013 0001 - 0782/13/01 ACM

如果您不是为了盈利或商业利益而制作或分发本作品的部分或全部,并在第一页注明本通知和完整引用,则允许您免费制作本作品的部分或全部数字或纸质副本,供个人或课堂使用。本作品的组成部分必须由ACM以外的其他人享有版权。信用文摘是允许的。以其他方式复制、重新发布、在服务器上发布或重新分发到列表,需要事先获得特定的许可和/或费用。请求发布的权限permissions@acm.org或传真(212)869-0481。

数字图书馆是由计算机协会出版的。版权所有©2013 ACM有限公司


没有发现记录

Baidu
map