数据库即服务是个坏主意吗?

  • Jean-Jacques Dubray
  • 王丽娟

2008 年 8 月 25 日

话题:架构语言 & 开发

云计算代表了业界一种重要的范式转变。David Chappell 指明

该转变中最重要的一部分是云平台的出现……这类平台允许开发人员编写运行在云中的应用,或利用云提供的服务,或者两者兼而有之。

即使这些平台看上去很普通,但 Dave 提出了告诫之词:

从相同的视角考虑 on-premises 平台和云平台是有用的,但两者是不同的。当平台功能移到云里时,这些功能有时会明显地变化。

Dave 将应用架构分为了三类:

  • 基础
  • 基础设施服务
  • 应用服务

Dave 还主张:

云应用可以构建在云基础之上,正如 on-premises 应用是基于 on-premises 建立的一样。两种应用都能获取 on-premises 和云中提供的基础设施服务和应用服务。就像 on-premises 平台支持现今的应用一样,云平台也为我们未来很可能创建的应用提供了服务。

在所有可能的基础设施服务中,“数据服务”可以说是最重要的,因为没有它们信息系统就不能建立。数据还代表主要的战略资产,因为提供最流行数据服务的云平台很可能会占有最大的市场份额。

Dave 断定了数据服务的不同类型:

云中的远程存储以不同的方式出现。比如说,Amazon 的简单存储服务(S3)提供了基本的非结构化远程存储。它暴露给开发人员的模型是直接了当的:仅仅是一堆字节的对象存储在存储桶中……

另一种云存储的方式是支持更加结构化的数据,比如在Microsoft 的 SQL Server 数据服务(SSDS)中,一个容器包含一或多个实体,其中每个都持有一定数量的属性。

可是 Arnon Rotem-gal-Oz 想知道“数据库即服务”是不是一个好主意。随着 Microsoft、IBM、AmazonLongJumpEnterpriseDB都试图提供本质上同类的功能,数据库即服务成为业界一种普遍的趋势。他解释说:

那为什么通过(RESTful 或其它的)Web 服务暴露数据库是错误的呢?让我娓娓道来

  • 它完全绕开了“服务”的思想——没有任何业务逻辑,它倾向于资源 / 服务的 CRUD 操作

  • 它暴露的是内部数据库结构或数据,而不是经过思考后的契约

  • 它鼓励忽视真正的服务,直接定位它们的数据

  • 它创建了一个 Blob 服务(数据源)

  • 它鼓励细微的 [半] 服务(上述 Blob 的多个“接口”),这忽略了少数分布式计算的错误

  • 它是披着羊皮的狼,只不过是客户 - 服务器模式

Seattle 的记者Andrea James 看到了另一个紧急的问题

对一个企业来说,从电源插座流出的电似乎是无穷尽的,也不用担心水龙头里流不出水来——企业只需要为他们使用的东西买单。但计算能力还没有如此无缝。

我们肯定只是刚刚接触了云平台的皮毛,没有结构化数据管理的某种形式,云平台是不会出现的。断定哪种数据服务和云编程模型会胜出似乎仍然为时过早。你会将你的企业数据托管到数据库即服务吗?你更愿意通过应用服务访问数据,还是仅仅对系统的记录进行 CRUD 操作呢?

查看英文原文:Is Database-as-a-Service a Bad Idea?

架构语言 & 开发