写点什么

微软世界中的 S+S

  • 2008-01-29
  • 本文字数:1852 字

    阅读完需:约 6 分钟

最近, David Chappell 发表了一篇名为《微软世界中的 S+S 》的白皮书,抛开微软是这份白皮书的赞助者这一背景不谈,对于那些想要了解微软提出的“S+S”战略的人来说,它倒是一份理想的材料。白皮书的副标题是“写给 IT 决策者的技术总览”,很显然这篇论文有一定的针对性。

微软是创造新名词的行家里手,这样做的目的往往更多的是出于市场方面的考虑。通过新名词,一来可以迅速的吸引众人的眼球,二来也可标榜自己与他人的不同,彰显企业的个性。至于其技术内涵,反倒被放在了第二位。无疑,微软的“S+S”又走上了以前“微软制造”的老路。很少有人能清楚地说明白微软的“S+S”战略到底是什么,认为“S+S=SaaS”的人恐怕不在少数,甚至有人认为 S+S 就是另一种形式的 RIA (注:见该文的评论)。面对媒体,微软对“S+S”的宣传内容也显得空泛,离确保该战略成功的执行层——第一线的开发人员——很远。

名词的制造者不一定是最佳的诠释者,在 COM 时代 Don Box 就已经为我们示范了一个先例。如今,David Chappell 又为我们贡献了一个样板。微软赞助这份白皮书的原因显然是为了更好地向技术人员普及“S+S”。微软这样做已经不是第一次了,在.NET 刚面世的那段日子里,微软就用过类似的手法——花钱请人撰写.NET 相关的技术文章。

从白皮书的内容来看,David Chappell 出色地完成了这项任务。文章的内容主要包含 3 部分内容:

  • S+S 介绍
  • 进一步了解服务
  • S+S 中的应用平台

对于那些急于了解“S+S”的人来说,白皮书的第一部分是一个非常好的起点。David Chappell 如此定义“S+S”:

……,S+S 的真实含义变得清楚起来:第一个“S”指的是内部(on-premises)软件——完全受控于使用它的组织的软件,第二个“S”即 SaaS。

“内部软件”并不是什么新鲜事物,它运行于组织内部(不一定是同一物理地点),要么是购买的成品软件,要么就是自行开发的系统。很明显,从这个定义上看,微软并不打算放弃在其收入比重中占有明显优势的软件业务,同时由于 SalesForce.com Google Amazon 等这类新型软件服务提供商的兴起,使得微软又一次将目光瞄上了 SaaS。如果你认为微软就此止步,那就大错特错了。作为平台提供商的微软深知平台的力量,在“S+S”战略中,应用平台同样也有其重要的位置:

无论如何,没有明显的理由说明这两种平台(注:内部软件平台和 SaaS 平台)应该显著的不同。事实上,很容易的想到有朝一日这些技术会聚合在一起。假使有一个对内部(on-premises)和 SaaS 环境都适合的单一平台,企业就可以在需要的时候移动应用程序。正如以后所描述的,微软正打算这样做,为内部(on-premises) 和 SaaS 应用提供单一的平台技术。

接着,白皮书从提供服务和服务计费两个方面对服务进行了进一步的说明。其中:

  • 提供服务
    • 定位消费者:企业用户还是普通消费者。前者是付费用户,使用高级功能,且一般有明确的 SLA(服务水平协议);后者是免费使用,使用大众功能,一般没有明确的 SLA(但是有隐式的 SLA。如果服务的质量不好,即使免费也不会有人使用)。
    • 选择实现风格:单租户还是多租户。前者是为每个客户起一个服务实例;后者则是多用户共享一个服务实例。
  • 服务计费,一般采用按使用功能付费的形式。

在最后一部分,白皮书以微软的 BizTalk 为例,说明了“S+S”中的应用平台的情况。对应“S+S”的定义,平台类型分为两种:(内部)软件平台和 SaaS 平台。软件平台,微软已经相当成熟,而目前努力的方向则是 SaaS 平台。白皮书明确区分了 SaaS 平台和可编程服务,其中最大的区别莫过于前者可以运行客户自己创建的软件,客户创建的应用在服务提供商处运行;而可编程服务只能被客户软件调用。最后,白皮书道出了微软的“S+S”战略中应用平台的愿景:

通过在两个平台提供相似的 API,开发人员在创建应用时,可以无需事先考虑它是否是内部运行或是作为服务运行。一个应用可能一开始是本地运行的,然后为了获得更大的容量和更低的成本转而移到一个服务提供商处运行。

作为微软赞助的白皮书,不可避免地会具有一定的倾向性。但是,通观全文并没有发现明显的贬低竞争对手,抬高自己的内容。而且文中所提的软件和 SaaS 并存的观点,在目前看来也确实具有其现实意义。值得注意的是,作为靠平台起家的微软,在“S+S”战略中也没有忘记对平台的控制,只是这一次它的野心要更大一些——创建一个适用于软件和 SaaS 的公共平台。这对于微软平台的 ISV 来说,无疑是个利好。这使得他们现有身份不变的同时,还有机会以较低的成本成为 SaaS ISV。面对微软联盟咄咄逼人的气势,其他联盟该如何反击呢?或许,这只是市场重新洗牌的开始。

2008-01-29 10:35943
用户头像

发布了 255 篇内容, 共 57.5 次阅读, 收获喜欢 10 次。

关注

评论

发布
暂无评论
发现更多内容

从0开始的TypeScriptの九:接口Interfaces · 中

空城机

typescript 大前端 8月日更

【Vue2.x 源码学习】第三十七篇 - 组件部分 - 组件的合并

Brave

源码 vue2 8月日更

docker的使用

Rubble

8月日更

【设计模式】备忘录模式

Andy阿辉

C# 编程 后端 设计模式 8月日更

可视化接口管理平台 YApi,让你轻松搞定 API 的管理问题

xcbeyond

工具 接口管理 YAPI 8月日更

传统企业数字化转型的三大技术误区

码猿外

数字化转型 敏捷精益

讲透学烂二叉树(三):二叉树的遍历图解算法步骤及JS代码

zhoulujun

二叉树 二叉树遍历 前序遍历 中序遍历 后续遍历

架构实战营毕业总结

林子钧

架构实战营 毕业总结

你真的了解 fail-fast 和 fail-safe 吗

4ye

Java 后端 并发 map 8月日更

LeetCode题解:220. 存在重复元素 III,暴力法,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

Linux之scp命令

入门小站

Linux

模块五作业

秀聪

架构训练营

10篇校招/社招面经请你查收~

王知无

讲透学烂二叉树(四):二叉树的存储结构—建堆-搜索-排序

zhoulujun

二叉树 堆排序 二叉堆 二叉堆排序 二叉树排序

毕业总结

梦寻解语花

架构实战营

【Flutter 专题】68 图解基本约束 Box (三)

阿策小和尚

Flutter 小菜 0 基础学习 Flutter Android 小菜鸟 8月日更

没有银弹

escray

学习 极客时间 如何落地业务建模 8月日更

随机字符串,随机密码生成器

入门小站

工具

架构实战营 毕业设计项目

梦寻解语花

架构实战营

JVM空间分配担保机制

W🌥

Java JVM 8月日更

企业研发效能提升之道 —— 管中窥豹,窥一斑而知全豹

在天涯的海角

研发效能

架构实战营毕业设计

林子钧

架构实战营 毕业设计

Spark RDD模型

Geek_qsftko

spark

讲透学烂二叉树(六):二叉树的笔试题:翻转|宽度|深度

zhoulujun

二叉树 二叉树遍历 二叉树翻转

架构实战营 - 模块五作业

思梦乐

悄悄学习Doris,偷偷惊艳所有人 | Apache Doris四万字小总结

王知无

TypeScript那些最佳实践

思诚^_^

typescript

《社会心理学》-怎样说服他人?

箭上有毒

8月日更

讲透学烂二叉树(五):分支平衡—AVL树与红黑树伸展树自平衡

zhoulujun

二叉树 平衡二叉树 红黑树

Seata TCC模式原理与实战

码农参上

分布式事务 seata SpringCloud Alibaba 8月日更

高并发中,那些不得不说的线程池与ThreadPoolExecutor类

华为云开发者联盟

Java 线程 高并发 线程池 ThreadPoolExecutor类

微软世界中的S+S_SOA_胡键_InfoQ精选文章